We put an LLM in a PostgreSQL analyzer, then stopped letting it decide truth

Elevarq released Elevarq Analyzer 1.0, a PostgreSQL monitoring and investigation tool that uses deterministic analysis to establish findings from evidence before using a language model to explain them, ensuring the model does not decide what is true. The tool runs inside the user's environment and can deliver implementation-ready tickets to GitHub, GitLab, Jira, or Linear, but does not execute changes against PostgreSQL.

Elevarq Analyzer 1.0: Evidence before explanation Today we're releasing Elevarq Analyzer 1.0. PostgreSQL monitoring and PostgreSQL investigation are two different jobs. Monitoring tells you that CPU increased, queries slowed down, or IO changed. Sometimes it tells you nothing while a problem develops underneath. The next step is investigation. What changed? Does it matter? Is this normal for the workload? What evidence supports the diagnosis? And what should we do about it? An experienced PostgreSQL DBA knows where to start looking. But even an experienced DBA has limited time. Nobody investigates every small anomaly when there are incidents to handle, migrations to prepare, and releases to ship. The small things wait. Most of them stay small. Some don't. Elevarq Analyzer keeps doing that investigative work across every database, including the things nobody has time to investigate today. How it works Elevarq Analyzer has three parts. Signals collects read-only evidence from PostgreSQL. Deterministic analysis evaluates that evidence and establishes findings. Insight explains those findings so an engineer can understand and act on them. When a finding requires action, it can be delivered to GitHub, GitLab, Jira, or Linear as an implementation-ready ticket, with the evidence and recommended change included. The workflow stops there. Elevarq Analyzer doesn't execute anything against PostgreSQL. Your team reviews the recommendation and decides. Database changes depend on context that lives outside database statistics: release schedules, application behavior, maintenance windows, business priorities. A plausible explanation is not a finding Modern language models know a lot about PostgreSQL. Give one enough statistics and context, and it will often produce an explanation that sounds like something an experienced engineer would say. That is useful. It is also dangerous. Consider HOT updates. PostgreSQL can avoid creating new index entries when an UPDATE changes no indexed columns and the new tuple version can be stored on the same heap page. When HOT updates happen less often than expected, insufficient free space on the page is one possible cause, and lowering fillfactor can be a remedy. A PostgreSQL-aware model knows this. Show it a table with a low HOT ratio and it may tell you to lower fillfactor. That might be right. But there is another possible cause: the UPDATEs touch an indexed column. If that's what's happening, fillfactor won't solve the problem. Unless the evidence establishes why HOT updates aren't occurring, the causes cannot be told apart. What the evidence establishes is that HOT behavior deserves attention. The fillfactor diagnosis is a hypothesis. During pre-release testing we 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. No evidence, no finding Telling the model to be careful helps. 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. We don't want the most plausible explanation. We want the explanation the evidence supports. So in Elevarq Analyzer, the language model does not decide what is true. Deterministic analysis establishes findings from the evidence. Insight explains them. If the evidence needed for a finding isn't there, the finding isn't reported. That can make an individual report look less clever. We think it makes the product more useful in production. An engineer reading a finding should never have to wonder whether it was established from evidence or guessed by a model. Your telemetry stays with you Elevarq Analyzer runs inside your own environment. Database metadata, schema, statistics, and workload characteristics are not things most organizations want to send to an external service. Analysis and explanation run locally. No database telemetry leaves your environment. What 1.0 means 1.0 does not mean Elevarq Analyzer knows every PostgreSQL failure mode. It doesn't. Detection will expand. Signals will collect more evidence. Models and explanations will improve. 1.0 means we stand behind the methodology. Four principles shaped this release: Deterministic detection first. Explanation follows evidence. No automatic changes. Elevarq Analyzer recommends. Your team decides. Telemetry stays in your environment. Analysis and explanation run locally. No evidence, no finding. A plausible explanation isn't enough. That last one took more work than we expected. It was worth it. Elevarq Analyzer 1.0 is available now. We're onboarding the first customers directly.