PGConf.EU 2026: Postgres gets radar and radar-analyst, open source duo for diagnosis without a resident agent

At PGConf.EU 2026, in Valencia, specialist Jimmy Angelakos presented radar and radar-analyst, which take a complete snapshot of the database without requiring an agent running, and detailed pg_statviz, which stores time series within Postgres itself.

PostgreSQL Conference Europe 2026 took place from October 20 to 23, at the Palacio de Congresos de Valencia, and brought together the European Postgres community around talks, panels, and community events. Among the attendees was Jimmy Angelakos, who reported on his blog, on Planet PostgreSQL, a packed week: a panel on production incidents, a technical talk, a signing session, and three community events on the same day.

For those who build and maintain production systems in Brazil, two of Angelakos' presentations are directly relevant: the pair of tools radar and radar-analyst, and the pg_statviz project. radar and radar-analyst are open source software under the PostgreSQL license; pg_statviz is also an open project. All three address a recurring problem: diagnosing a database after the incident has already happened, without needing a monitoring agent that was already standing by.

The problem of the agent that wasn't running

Anyone who has ever been on call for production knows the scenario. A monitoring agent only helps if it was already active before the problem started. The Postgres log shows only what the queries did, not the state of the operating system or the current configuration. And the rest of the investigation turns into an email exchange asking for a screenshot of this, the output of that command, the version of such a parameter.

radar attacks this specific point: it is a single static Go binary that collects, in seconds, a snapshot of PostgreSQL and the host into a single zip file, and then exits. It does not capture row data or passwords, only metadata: system catalogs, cumulative statistics, and configuration. This solves the distribution problem (no need to install anything permanent) without giving up control over the data surface that's sensitive to leaks.

radar-analyst is the second half of the pair, and it's what turns the zip into a diagnosis. The tool runs a deterministic set of rules over the collected file, assigns a verdict to each evaluated category, and links each finding to a suggested fix. A language model can, optionally, draft a summary on top of that, the way a senior DBA would when explaining the report, but Angelakos was categorical on one point during the presentation: only the deterministic rules can create a finding, and the model can never soften the verdict they have already set.

This separation matters more than it seems. In AI-assisted diagnostic tools, the classic risk is the model "softening" a real problem to sound milder in the summary, or inventing a plausible cause that isn't in the data. By locking the verdict layer to the rules and leaving the AI to only narrate, radar-analyst avoids that kind of hallucination exactly where it would hurt most: in the report that goes to the manager deciding whether to escalate the incident.

pg_statviz: time series without an external exporter

The second tool detailed by Angelakos, at the PostgreSQL Observability Summit on the conference's community events day (the conference's Friday), tackles a different problem: continuous observability, not a one-off snapshot. pg_statviz makes use of the cumulative statistics that PostgreSQL itself already keeps internally and writes them into tables within the same monitored database, turning them into time series that can be queried and visualized without an external agent or an exporter running alongside it.

The logic is similar to radar-analyst's on the AI side: the optional layer hands the generated charts, as images, to a vision-capable language model, because, according to Angelakos, "the chart is what a DBA actually reads" when investigating a degradation trend. Again, the deterministic rules have the final word on the verdict; the AI only reads and comments on what has already been calculated.

For teams that currently depend on external observability stacks (Prometheus with an exporter, Datadog, New Relic) to track Postgres metrics, pg_statviz is not a substitute for full infrastructure monitoring. It serves a narrower case: small teams, isolated environments, or databases where installing and maintaining an external agent is operationally costly, but that still want a history of the database's internal metrics without leaving Postgres itself.

When each tool makes sense, and when it doesn't

The table below summarizes the use case for each approach, based on what was presented at the conference:

Neither of Angelakos' two tools replaces a mature observability stack. Their value lies in covering the gap between "I have nothing monitoring this" and "I need to understand what just happened," which is exactly the situation a good portion of Brazilian teams find themselves in when their production Postgres hits a problem without warning.

What the confessions panel already made clear

On the conference's Tuesday, Angelakos took part in the panel Postgres On-Call Confessions: Worst Practices 101, alongside Ants Aasma, Mayuresh Bagayatkar, Hettie Dombrovskaya, Pavlo Golub, and Teresa Lopes. The idea was simple: gather the "obvious fixes" that, in practice, made a production incident worse, and open the mic for the audience to confess their own.

The pattern that emerges from this kind of panel, recurring at Postgres conferences, is always the same: a fix applied under pressure, without understanding the execution plan behind the symptom, tends to trade a visible problem for a silent one. That's the backdrop that justifies tools like radar-analyst: deterministic rules, applied consistently, tend to get it wrong less often than a tired DBA deciding at three in the morning whether to restart the server or kill the query.

Onboarding: the obstacle nobody had measured

A parallel finding, less technical but relevant to anyone training newcomers to Postgres in Brazil, came from the PostgreSQL Training Materials Working Group, led by Angelakos and Hettie Dombrovskaya on Friday. The group did a live demonstration of the postgresql.org site from the point of view of a complete beginner, and the outcome wasn't flattering for the official site.

In short: the group counted 14 clicks before finding where to start, plus 7 more clicks on the download page before reaching anything copy-pasteable on Linux, with no automatic operating system detection, no sandbox for anyone whose laptop is locked down by corporate policy, the first psql fails because of pg_hba.conf, and then the beginner is instructed to create a database without being told why. The group concluded that there's no need to create new material from scratch: an official tutorial, third-party courses, exercise sites, and sandboxes already exist in sufficient number; it's just a matter of organizing and linking what already exists into a coherent onboarding flow.

For anyone building a junior team or giving internal Postgres training, this mapping is a useful shortcut: instead of writing a tutorial of your own from scratch, it's worth reviewing the material that already exists with the same critical eye as the working group before pointing any link to the new team.

What changes in practice

None of the tools presented solves the modeling and integrity work that remains the foundation of any healthy database, and Angelakos never promised to solve that. What radar, radar-analyst, and pg_statviz address is the distance between "something went wrong" and "I know exactly what to fix," without depending on an observability stack already installed when the problem shows up.

For Brazilian teams running Postgres without a full-time dedicated DBA, the combination is a low-cost starting point: radar as an emergency tool, to run and send at the moment of the on-call ticket, and pg_statviz as a lightweight history of internal statistics while the team doesn't yet invest in a full observability stack. The caveat worth repeating is the same one Angelakos made a point of stressing in both presentations: the optional AI narrates, but the verdict is still decided by the deterministic rule written by someone who understands Postgres from the inside.