Arq

PostgreSQL intelligence platform. Continuous detection, root-cause diagnosis, and resolution guidance for teams that need precision.

Arq detects problems in your PostgreSQL databases, explains why they happen, and tells you exactly how to fix them. It is not a dashboard. It is a diagnosis and guidance system that improves every database decision your team makes.

Arq runs continuously alongside your database, building context over time. Early on, it finds the obvious wins. Over weeks and months, it catches slow regressions, identifies configuration drift, and guides capacity decisions.

Components

Each part is independently understandable. Together they form a single flow: collect evidence → diagnose → review → create ticket.

Arq Signals

Read-only PostgreSQL telemetry collector. Gathers execution statistics, wait events, connection metrics, and configuration state into portable snapshots. Open source; runs in your infrastructure with no schema changes and no data exfiltration.

Arq Analyzer

Evidence-grounded PostgreSQL diagnosis engine. Applies deterministic detection rules — vacuum lag, index bloat, query regressions, WAL retention, and more — to Signals snapshots, then enriches each finding with Arq Insight: bounded LLM explanations grounded in cited evidence.

Arq Workbench

Operator-facing web UI. Review findings, manage triage status, and push implementable tickets to GitHub Issues, Jira, and other ticket systems. Self-hosted; one instance per organization.

What Arq produces

One rendered example. Every finding Arq emits follows the same 9-field structure — a senior DBA's diagnosis written out so any team can implement it.

Arq Signals snapshots the operational state of your PostgreSQL instance. The Analyzer runs deterministic detection rules against the snapshot and surfaces hits. Arq Insight enriches each hit with a diagnosis, citing the specific evidence — never inventing new findings, never escaping the cited evidence. The output looks like this:

Sample finding · rule indexes.missing.v1

Missing index candidate on `public.events.user_id`

Severity: mediumConfidence: 0.85

Problem

Frequent sequential scans on public.events filter on user_id. The evidence indicates that this access pattern is worth an operator's review.

Why it matters

This query is on the hot read path and runs frequently. Current execution wastes shared-buffer cache on rows that the predicate then discards. The gap widens as public.events grows; addressing it now is cheap and reversible.

Evidence

queryid = 0xab12cd34
calls = 1,247,392 over 24 hours
mean_exec_time_ms = 11.7
Source refs: indexes.missing.v1, table=events, column=user_id

Recommended action

Create a single-column index on user_id. Use CONCURRENTLY so the build does not block writes onpublic.events; note that CREATE INDEX CONCURRENTLY cannot run inside a transaction (a common gotcha for migration tools that wrap each statement by default).

CREATE INDEX CONCURRENTLY idx_events_user_id
  ON public.events (user_id);

The names, query identifier, and numerical values above are illustrative. The fields shown — diagnosis, why it matters, cited evidence, recommended action, plus the calibrated severity and confidence in the header — are what Arq emits for every finding. The richer triage shape that downstream operators expect in their tracker (implementation steps, rollback, when to escalate) is part of the review workflow before push. Talk to us about an evaluation to see findings like this against your own database.

Key capabilities

--Root-cause grouping: correlated symptoms surfaced as a single finding, not separate alerts
--Regression detection tied to specific deployments, schema changes, or config updates
--Execution-based analysis using actual row counts, buffer hits, and timing
--Targeted recommendations tied to cited evidence, not generic best practices
--Operator-ready findings that support controlled remediation review
--On-premise deployment: your data stays in your network

Deployment

Arq runs in your infrastructure. It connects to PostgreSQL using read-only credentials via the standard protocol. No agents to install on database hosts, no schema changes, no sidecar processes.

Designed for environments subject to SOC 2, PCI DSS, and financial regulatory requirements. Query text and result data never leave your network.