How Arq works
Four stages from a read-only PostgreSQL snapshot to an implementable triage ticket. Arq spots the correlations, pitches the change, and shows the evidence. A human decides yes or no, plans the rollout, and ships the fix.
Arq does not run your database. It observes it, correlates what it sees against deterministic detection rules, and writes up what looks worth investigating. Every finding lands with the evidence inline — the snapshot rows and catalog values — so the team owning the database does not have to copy-paste between dashboards to verify.
Spotting correlations across hundreds of catalog views, query statistics, and configuration values in seconds is the part Arq does faster than any single engineer. Deciding whether the fix is safe to ship at 14:00 on a Tuesday, whether the maintenance window is wide enough, whether the table is hot enough to make a CONCURRENTLY build worthwhile — that is the part the DBA, the DevOps engineer, or the developer who owns the service is paid to do. Arq pitches. Humans decide.
The pipeline
Signals collects. Analyzer correlates. Insight explains. Workbench presents. Each stage is independently testable; each artifact between stages is a file you can inspect.
Arq Signals
Read-only snapshot of execution stats, wait events, catalog state, and configuration. Runs on your schedule. Writes a portable snapshot.zip.
Arq Analyzer
Deterministic detection rules run against the snapshot and produce evidence-linked findings. Output: findings.json + report.json.
Arq Insight
Each finding is enriched with a bounded LLM diagnosis grounded in the cited evidence. Insight cannot invent findings, cannot escape the evidence, and cannot promote severity.
Arq Workbench
Operator UI. Review the pitch, walk the evidence, accept or reject, plan the rollout. Push the ticket to GitHub Issues, Jira, or your tracker when you're ready.
Signals collects what Arq needs, nothing it does not
Arq Signals connects with read-only credentials and queries PostgreSQL catalog views, statistics views, and configuration state. It does not connect to the data itself. There is no schema change, no agent on the database host, no sidecar process.
Safety is enforced in three independent layers. Every SQL statement Signals ships is reviewed against a static lint rule that rejects writes. Every session opens with default_transaction_read_only = on. Every query is wrapped in a per-query READ ONLY transaction block. If any layer is bypassed in a build, the next one catches the slip.
Signals writes a single portable snapshot.zip. The file is plain text JSON, gzip-compressed. You can open it, diff it across collection runs, and feed it to the Analyzer offline. Signals is open source under BSD-3-Clause — auditors can read the safety enforcement themselves.
Analyzer is the part that sees patterns faster than a human
The Analyzer reads the snapshot and runs every shipped detection rule against it. Vacuum lag, index bloat, long-running transactions, query regressions tied to plan changes, WAL retention, configuration drift — each rule fires deterministically when its evidence threshold is met, and never when it is not.
The correlation work is the lift. A human reading a single catalog view can spot a problem; correlating wait events against per-statement timing against configuration changes against vacuum progress across an hour-long window is tractable for one query at a time and intractable across the fleet. The Analyzer does it in seconds against the whole snapshot.
Findings from the Analyzer identify the captured evidence and supporting context that an operator needs for review. The output — findings.json and report.json — is plain text, diffable, and survives transport between airgapped environments.
Insight pitches the change, then steps back
Insight is the layer that writes the pitch. For each finding, it produces a paragraph of context: what the signal indicates, why the deterministic rule fired, what the cited evidence actually shows, what the recommended action is, and what changes if the action is taken.
The LLM's job is to write the pitch a reviewer can read in thirty seconds — not to decide the diagnosis. The deterministic rules already decided that, and Insight cannot override them. It cannot invent a new finding. It cannot promote severity. It cannot escape the cited evidence. If a finding has no evidence for a claim Insight would otherwise write, the claim does not get written.
The narrowness is on purpose. The reviewer reading the Workbench gets the explanation a senior DBA would write, and the evidence is exactly the evidence the deterministic rule already cited. There is no LLM-generated number on the page that did not come from the snapshot.
Workbench is where the human decides
A DBA, a DevOps engineer, a developer who owns the service — whoever is paid to call the shot — opens the Workbench, reads the pitch, walks the evidence, and makes a decision. Accept, reject, defer, ask for more context. Tag the finding, attach a note, assign it to the right person.
When the decision is to ship, the Workbench pushes an implementable ticket — diagnosis, why-it-matters, evidence, action, ordered implementation steps, validation, rollback, escalation criteria — to GitHub Issues, Jira, or whatever tracker the team already uses. The push is one-way and idempotent: running it twice for the same finding does not create two tickets.
Reduced manual work in this stage is the point. The reviewer is not assembling the ticket. They are deciding whether the ticket is worth shipping, and the ticket arrives ready to hand to whoever ships it. No copy-paste from monitoring dashboards. No re-typing query plans into a description field. The implementation steps are already there.
What Arq does not do
The boundaries matter as much as the capabilities. Security review will ask; here are the answers up front.
No live database connection
Analyzer and Insight read the snapshot file, not the database. The only component that connects to PostgreSQL is Signals, and it does so with read-only credentials on a schedule you control.
No continuous monitoring
Arq runs on snapshots, not streams. Each run is a point-in-time analysis. Continuous monitoring is what your APM and pg_stat_statements already do; Arq sits above that layer.
No autonomous remediation
Arq does not run ALTER, CREATE INDEX, or anything else against your database. It writes tickets. A human reviews and ships.
No telemetry to Elevarq
The product is offline-activated. Snapshots, findings, and tickets stay in your network. Elevarq does not receive usage data, query content, or anything else from your deployment.
The full data-boundary model lives on the security page, written for the procurement and security-review conversations an enterprise buyer runs.
Two ways to start.
See the full Arq pitch and a rendered sample triage ticket, or download the open-source collector and point it at your own database.