How Elevarq Analyzer works
Elevarq continuously analyzes read-only PostgreSQL snapshots and turns them into implementation-ready tickets in the tracker your team already uses. Four stages: it spots the correlations, pitches the change, and shows the evidence — then your team decides and ships it, right in its existing ticket workflow.
PostgreSQL problems rarely begin as incidents
By the time PostgreSQL surfaces as an incident, the conditions behind it have usually been developing for a while — unexamined, because there was never engineering time to look. Interrupt-driven firefighting then consumes the very capacity that would have prevented the next incident.
- Query plans change as data and workloads evolve
- Statistics and selectivity drift
- Replication lag grows under write pressure
- Configuration stops matching the workload
- I/O, WAL, and resource pressure accumulate
- Security and privilege issues develop quietly
Every finding analyzed — even the ones nobody had time for. Most developing conditions were never examined at all: not because they did not matter, but because there was never engineering time. Elevarq evaluates every snapshot against every applicable rule, every run, surfaces the conditions the evidence supports, and hands your team the analysis before they become incidents.
Elevarq Analyzer 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 Elevarq Analyzer 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. Elevarq Analyzer 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.
Elevarq Signals
Read-only snapshot of execution stats, wait events, catalog state, and configuration. Runs on your schedule. Writes a portable snapshot.zip.
Elevarq Analyzer
Deterministic detection rules run against the snapshot and produce evidence-linked findings. Output: findings.json + report.json.
Elevarq Insight
Each finding is enriched with a local AI explanation grounded in the cited evidence. Insight cannot invent findings or promote severity; explanations that go beyond the evidence are discarded and the deterministic explanation is used instead.
Your tracker
Each finding arrives as a ready-to-ship ticket in GitHub, GitLab, Jira, or Linear. Your team decides and ships it there, in the ticket workflow it already runs. Elevarq Workbench is where you set that up — not a dashboard you have to live in.
Signals collects what Elevarq Analyzer needs, nothing it does not
Elevarq 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 — the quiet problems that slow a database down or make the next change risky: maintenance falling behind, transactions holding things up, a query that regressed after a change, configuration that has drifted (in PostgreSQL terms: vacuum lag, index bloat, long-running transactions, plan-change regressions, 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. And what it writes is not taken on trust: every explanation is validated against the finding's evidence, and if a claim goes beyond what that evidence supports, the narration is discarded and the deterministic explanation is shown in its place.
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.
The decision happens in the workflow you already use
You set Elevarq up once in the Workbench — connect your databases, connect your trackers, and tune what gets raised. After that, most teams work almost entirely in their own tracker. Each finding arrives as a ticket in GitHub, GitLab, Jira, or Linear, and whoever owns the change decides what to do with it — accept, prioritize, defer, or close — using the same review and approval process the team runs for every other ticket.
The ticket is not just an alert. It arrives implementation-ready: the diagnosis, why it matters, the cited evidence, the ordered implementation steps, how to validate, how to roll back, and when to escalate. Nobody copy-pastes from a monitoring dashboard or re-types a query plan into a description field — the work is already written up, ready to hand to whoever ships it. The push is one-way and idempotent, so re-running a finding never creates a duplicate.
The Workbench is still there when you want it — to walk the full evidence behind a finding, manage triage across runs, or adjust configuration. But it is not a place your team has to live. Elevarq meets your workflow where it already is: a human still reviews every change and ships it through your normal controls, and nothing is ever run against your database for you.
How Elevarq keeps the AI honest
The AI explains — it never decides, invents, or leaves your network.
The rules decide; the AI explains
Findings and their severity come from deterministic detection rules, not the model. The model never invents a problem or inflates one — it puts the deterministic result into plain language.
Every explanation is checked against the evidence
Each explanation is validated against the finding's cited evidence. Anything that goes beyond it is discarded and the deterministic explanation is shown instead — so what you read is always backed by the snapshot.
Local models, trained for PostgreSQL
Insight runs local models trained specifically for PostgreSQL (and TimescaleDB on Professional and above) — not a general-purpose cloud LLM pointed at your database.
Your data never trains our models
Elevarq is offline-activated and runs entirely in your environment. Your snapshots and query content never leave your network and never train Elevarq's models — and there is no per-token billing or usage cap.
What you can count on
The guarantees procurement and security review look for — by design, not bolted on.
Never touches production
Only Signals reads your database — read-only, on a schedule you control. Everything after that runs off-production: Analyzer and Insight never connect to it. The analysis runs in an isolated Report Database — the same PostgreSQL major you run in production, from the information Signals collected — so no customer query runs, and no query-execution load, locks, or cache disruption touch production.
Continuous analysis — that tells you what to do
Elevarq analyzes your database run after run, on the schedule you set, and hands you the diagnosis and the fix. A dashboard shows a line trending up or down and leaves you to work out what it means and what to change. Elevarq has already done that part.
You stay in control
Elevarq recommends and writes the ticket; a human reviews and ships every change through your normal controls. The database changes — ALTER, CREATE INDEX, and the rest — are always yours to make.
Your data stays in your network
Elevarq is offline-activated. Snapshots, findings, and tickets stay in your environment; usage data, query content, and everything else stay with you.
The full data-boundary model lives on the security page, written for the procurement and security-review conversations an enterprise buyer runs.
Recovered capacity becomes improvement capacity
Elevarq doesn't replace your team's expertise. It changes where scarce engineering time is spent — from investigating incidents to preventing them.
- Incident
- Interrupt planned work
- Investigate from zero
- Find the root cause
- Emergency remediation
The next escalation controls the calendar.
- Ongoing analysis, on your schedule
- The condition found early
- Evidence and root cause already there
- Review & schedule the fix
- Planned remediation
Planned work, on your calendar — not the next escalation’s.
Time recovered for the work that prevents the next incident:
- Query & schema optimization
- Configuration & indexing
- Capacity planning
- Security & technical debt
- Application & database improvements
In the cloud, the payoff can reach the bill directly
Once a database has real, measured performance headroom, you have room to spend less on it. Teams can right-size over-provisioned instances and provisioned I/O, and consolidate workloads — running several applications or databases on a single, replicated instance — because the headroom is there and the analysis gives you the confidence to do it. Capacity you were paying for only to absorb un-diagnosed problems becomes capacity you can hand back.
Fits the workflow you already have
Elevarq doesn't ask your team to adopt a new tool or watch another dashboard. Once it is set up, every finding becomes a ready-to-ship ticket in the tracker you already use — and your team decides and ships it there.
- Lands where you work — GitHub, GitLab, Jira, and Linear, not one more dashboard to check.
- Through your controls — normal review, approvals, and CI/CD; nothing bypasses change management.
- Ready to ship — diagnosis, steps, validation, rollback, and escalation, already written.
- You stay in control — one-way and idempotent; a human decides, and nothing runs against your database.
Works with the tracker you already use
Every finding becomes a ticket in the system your team already runs on. Elevarq integrates with GitHub, GitLab, Jira, and Linear — the fix lands where your team already works.
GitHub
GitLab
Jira
Linear
GitHub, GitLab, Jira, and Linear are trademarks of their respective owners. Elevarq is not affiliated with, or endorsed by, them.
Two ways to start.
See the full Elevarq Analyzer pitch and a rendered sample triage ticket, or download the open-source collector and point it at your own database.