PostgreSQL Conference Europe 2026

PostgreSQL diagnostic tooling today asks you to compromise. Either you install an invasive agent on the database server before the incident: Datadog, Prometheus exporters, telegraf, monitoring sidecars, vendor agents, take your pick. Each comes with its own attack surface, dependencies, and update schedule. Or you can point pgBadger at your Postgres log after the fact, but logs only describe what your queries did, not deep server info: configuration, HBA rules, replication topology, Postgres statistics, the kernel and I/O configuration underneath.

radar is the missing piece. An agentless, zero-dependency Go binary that captures a comprehensive PostgreSQL + system snapshot in seconds: host facts, settings, HBA, roles, replication, WAL state, per-database tables / indexes / sequences / extensions, pg_stat_statements when loaded, and dozens of catalog and /proc files. It captures metadata only: no row data, ever. There's no scheduled job or resident daemon, no Python or systemd dependency. It's safe to drop on any production box, and every collector is skippable on demand. Output is a zip file the operator can forward to any support team.

radar-ui can be the analyst on the receiving end. A service that parses every entry into typed records and runs deterministic rules across five categories (Host & OS, PostgreSQL Configuration, Workload, Internals & I/O Health, Replication) plus per-database analysis. Every finding pairs a fact with a fix: "198 recent WAL archive failures", "oc_filecache has 56% dead rows". An LLM (OpenAI compatible, Claude, Gemini, or local Ollama) optionally synthesises each category into the kind of summary a senior DBA would write: invaluable for time-pressed operators.

The talk covers:

• The collector. What radar captures, what it deliberately doesn't, and how the agentless / zero-dependency posture can serve Linux, macOS, bare-metal, VMs, and containers.
• The rule pack. A walk through what radar-ui catches in real production snapshots, such as WAL archiver failures, idle-in-transaction blocking vacuum, sequences nearing exhaustion, bloat, and dozens more.
• The verdict. How findings reach the operator: deterministic status tags first, optional AI synthesis second, with a severity floor that prevents the model from softening CRITICAL to "consider investigating".

You'll leave the presentation with a concrete catalogue of the issues a structured PostgreSQL snapshot surfaces (and which a human can definitely miss), and an invitation to extend the rule pack: radar and radar-ui are open source.