PostgreSQL monitoring and PostgreSQL investigation are two different jobs, and most tools only do one of them. Monitoring tells you that CPU increased, queries slowed down, or IO changed. Investigation asks what changed, whether it matters, whether it is normal for the workload, and what evidence supports the answer. Elevarq Analyzer 1.0, released today, is a tool designed to do the second job across every database in an organization, including the ones nobody has time to look at.

The gap between signals and action

Experienced DBAs know where to start looking when something goes wrong. But even experienced DBAs have limited time. Incidents to handle, migrations to prepare, releases to ship. The small anomalies wait. Most of them stay small. Some do not. Elevarq Analyzer is built to do that investigative work continuously, rather than only when a human has bandwidth to look.

The tool has three parts. Signals collects read-only evidence from PostgreSQL, pulling metadata, schema information, statistics, and workload characteristics. Deterministic analysis evaluates that evidence and establishes findings based on what the data actually shows. Insight then explains those findings so an engineer can understand them and decide what to do. When a finding requires action, it can be delivered as an implementation-ready ticket to GitHub, GitLab, Jira, or Linear, with the evidence and recommended change included.

The workflow stops at the recommendation. Elevarq Analyzer does not execute anything against PostgreSQL. The team reviews and decides. Database changes depend on context that lives outside database statistics: release schedules, application behavior, maintenance windows, and business priorities. The tool surfaces the evidence and the recommendation, then leaves the decision to humans.

Why deterministic analysis matters

The most important design decision in Elevarq Analyzer is that the language model does not decide what is true. Deterministic analysis establishes findings from the evidence. The model explains them. If the evidence needed for a finding is not there, the finding is not reported.

This matters because LLMs can produce explanations that sound exactly like something an experienced engineer would say, while going further than the evidence justifies. Consider HOT updates, where PostgreSQL avoids creating new index entries when an UPDATE changes no indexed columns and the new tuple version fits on the same heap page. When HOT updates happen less often than expected, insufficient free space is one possible cause, and lowering fillfactor is a common remedy. A PostgreSQL-aware model knows this and will often suggest lowering fillfactor.

But there is another possible cause: the UPDATEs touch an indexed column. If that is what is happening, fillfactor will not solve the problem. Unless the evidence establishes why HOT updates are not occurring, the two causes cannot be told apart. The evidence says HOT behavior deserves attention. The fillfactor diagnosis is a hypothesis. Elevarq Analyzer reports the first and clearly labels the second as a recommendation rather than a finding.

During pre-release testing, the team kept finding cases like this: explanations that were technically plausible but went further than the evidence justified. A technically correct explanation can still be an incorrect finding. Telling the model to be careful helps, but it is not enough. A language model is built to produce the most useful continuation, and supplying the likely explanation is usually what makes it useful. Elevarq Analyzer wants the explanation the evidence supports, not the most plausible one.

Telemetry stays local

The tool runs inside the user's own environment. Database metadata, schema, statistics, and workload characteristics never leave the organization's infrastructure. Analysis and explanation run locally. This is a deliberate choice for organizations that do not want to send database telemetry to an external service, which is a reasonable security posture for any production database.

The no-automatic-changes principle is equally firm. Elevarq Analyzer recommends. The team decides. This separation matters because database changes depend on context that no monitoring tool can see: when the next release ships, whether the application is about to get a traffic spike, whether a maintenance window is available. The tool provides the evidence and the recommendation. The humans provide the judgment.

What 1.0 means

The 1.0 designation does not mean the tool knows every PostgreSQL failure mode. Detection will expand, signals will collect more evidence, and explanations will improve. What 1.0 means is that the team stands behind the methodology. Deterministic detection first. Explanation follows evidence. No automatic changes. Telemetry stays local. No evidence, no finding.

The last principle took more work than expected. Getting a language model to stop at what the evidence supports, rather than producing the most plausible continuation, required significant engineering effort. But the result is a tool where an engineer reading a finding should never have to wonder whether it was established from evidence or guessed by a model. That is a bar worth clearing, and Elevarq Analyzer 1.0 clears it.

For teams managing PostgreSQL at scale, the tool addresses a real gap. Monitoring tools are everywhere. Investigation tools that can reason across an entire fleet, establish findings from deterministic evidence, and present them with clear recommendations are rare. The 1.0 release is available now with direct onboarding for early customers.