Explanation

Evaluation guide

A practical path through evaluating Elevarq Analyzer end-to-end: what you need, a one-hour flow, how to judge the output, and where to go next. For the pipeline, the data-boundary model, and the finding schema in depth, this guide links the canonical pages rather than repeating them.

When Analyzer fits

Elevarq Analyzer turns PostgreSQL operational signals into implementable triage tickets — senior-DBA-level diagnosis, packaged for the team that ships the fix. It is not a dashboard, a metrics-alerting system, or a continuous monitor: it works on snapshots, and its output is a finding you hand to whoever owns the database. Reach for it when you run PostgreSQL in production without dedicated senior-DBA capacity, your dashboards say something is wrong but not what to do, and data egress matters. It is the wrong tool for real-time alerting or autonomous remediation — applying the fix stays operator-controlled by design.

For the full product narrative and a rendered sample finding, see the Analyzer product page. For how the components fit and what crosses the boundary, see Architecture & the pipeline and the data-boundary & safety model.

Prerequisites

Five things a platform team can line up in an afternoon:

A target PostgreSQL instance, version 14–18. Any deployment shape works — bare metal, VM, container, or a managed service that exposes the standard statistics views.
A monitoring role with pg_monitor-grade privileges. Least-privilege and read-only. No superuser — Signals rejects superuser and replication roles before collection starts, so the safe role is also the only role that works.
A host for the collector. Anything that runs Docker, or a Linux host with systemd for the binary install. The collector runs in your network, next to the database.
An outbound path for the snapshot export. Signals exposes a bearer-token-authenticated local API; you pull snapshot.zip from it and move the file to wherever the Analyzer runs. Nothing is pushed anywhere automatically.
An evaluation license. Evaluation licenses are issued by a human, not a signup form — typically valid for around 14 days. Request one via the contact path; commercial licensing afterwards runs through the pricing page and activates offline.

Install instructions live with each component. The Elevarq Signals repository covers the collector quickstart, the monitoring-role setup, and the export API; deploying Workbench is the getting-started tutorial.

A one-hour evaluation flow

The shape of an evaluation, end to end:

Try Elevarq Signals on its own (~10 min). Run the open-source collector against your own database. The snapshot it produces is exactly what the commercial Analyzer consumes — and you confirm the safety model hands-on: read-only access, no schema changes, no data exfiltration.
Provision Workbench. One container, two volumes, one license activation — the getting-started tutorial walks it.
Point Elevarq Analyzer at your snapshot. The analyzer runs against your real Signals data and emits findings, so you see what the tickets look like with your data shapes — not a canned demo.
Test a ticket push (optional). Wire up GitHub, GitLab, or Jira credentials and push one finding to your tracker — Connect a ticket system.

The same flow, summarised for whoever approves the evaluation, lives in the evaluation section of the pricing page — including the booking path. A reproducible proof-pack of known PostgreSQL scenarios through the licensed pipeline is available on request if you want to see expected output before connecting a database.

How to judge the output

A generated ticket is written to be handed over — closer to the write-up a consultant leaves behind than to a monitoring alert. Beyond the diagnosis, evidence, and recommended action (the full schema is in the finding-format reference), each finding carries a structured decision card — the part that makes the hand-off work, because it shows the reasoning rather than just the conclusion:

Action — the single recommended change, stated as the decision on the table.
Signal strength — a recommendation-strength score, not a probability. It expresses how strongly the evidence supports taking the action; a low score means the evidence converged weakly, not that the problem is unlikely to exist.
Evidence — the key points behind the recommendation, each attributed to the collector it came from, so you can trace every claim back to the statistics source that produced it.
Alternatives considered — the other plausible responses, each with a verdict and the reason it lost — including, where relevant, doing nothing.
Expected outcomes — what should improve if the action is taken, always labelled as estimated with the basis stated, never a guarantee.
Caveats — the conditions under which the recommendation is weaker or the remediation needs extra care: maintenance windows, lock behaviour, workload assumptions.

Lifecycle: findings resolve themselves

Findings are not manually closed. Once the remediation lands, the next collection-and-analysis cycle re-evaluates the same evidence — and a finding whose underlying signal is gone resolves on re-collection. That closes the loop the way a consultant would: apply the change, measure again, confirm the problem is no longer there.

Reading a ticket in practice: start with the action and its signal strength, walk the evidence to confirm it matches your data, scan the alternatives to see what was ruled out and why, then treat the remediation SQL as a reviewed change like any other — your normal deployment process applies. Analyzer never executes anything against your database.

Where to next

Deploy: Get started with Elevarq Analyzer.
Procurement / security review: the Security page and the safety model.
Talk to us about an evaluation: contact the team.