PostgreSQL RPM Brings AI-Powered pg_statviz to RHEL, SLES, and Amazon Linux

Devrim Gündüz, maintainer of the PGDG RPM repositories, detailed how pg_statviz began offering analysis via Claude, GPT, Gemini, and Ollama across six Linux distribution families, and why it took three days of packaging work.

What pg_statviz Does, and What Changed in It

pg_statviz is a lightweight utility that takes periodic snapshots of PostgreSQL's internal views (the pg_stat_* views) and turns that historical series into charts. None of this is new in itself. What changed, according to the post published this Monday (October 12) by Devrim Gündüz, maintainer of the PGDG RPM repositories and Principal Systems Engineer at EDB, is the analysis layer that recent versions of the tool began offering: taking those numbers and asking a language model to explain them in plain text.

The concrete news isn't this layer itself, which already existed, but its availability. Until last week, pg_statviz's AI feature only really worked on Fedora, because it's the only distro that already bundles SDKs recent enough. With Friday's release (October 9), the pg_statviz analyze command now talks to all four providers (Anthropic's Claude, a local Ollama model, OpenAI, and Google's Gemini) across the entire matrix of systems that PGDG packages: Fedora 44+, RHEL 9.8, RHEL 10.1 and 10.2, Amazon Linux 2023, SLES 16.0, and openSUSE Leap 16.0.

The Obstacle Was Packaging, Not AI

The problem, as Gündüz describes it, is a mismatch between two worlds that evolve at different speeds. AI SDKs (anthropic, openai, google-genai) are released every week and already require pydantic 2 with a Rust core, httpx2, and license metadata in PEP 639 format. Enterprise distribution Python toolchains, on the other hand, are frozen for years to guarantee stability.

The per-distro diagnosis reported in the post shows just how big the mismatch is:

The rule Gündüz imposed on the work was not to replace any operating system package: RHEL 9's numpy 1.24 remains untouched, because scipy and the GDAL bindings depend on it. The solution, for each SDK, was to choose the newest version that still compiles against what the distro already has, not the newest version available upstream. The result is a deliberately uneven version matrix: anthropic 0.40.0 on almost everything, but openai 2.28.0 on RHEL 9 and Amazon Linux 2023 versus 1.39.0 on RHEL 10 and SLES 16 (the latter with a hand-applied httpx 0.28 patch).

Underneath the four SDKs, Gündüz also had to package a new stack of pgdg-python3-* dependencies: pydantic 2.11.10, pydantic-core, jiter 0.17.0, maturin, httpx, httpcore, anyio, google-auth 2.47.0, and about twenty other packages. The Rust parts (jiter, maturin, pydantic-core) were compiled offline from vendored crates, with scripts kept alongside the specs in the project's Git repository.

Why This Matters to Those Investigating Bottlenecks, Not Just Packagers

The angle that matters for infrastructure isn't the dependency saga itself, but what it unlocks: a team that already runs pg_statviz to track resource usage trends can now ask, in the same workflow, for a model to explain in natural language what the pg_stat_bgwriter, pg_stat_database, or pg_stat_user_tables charts are showing. For whoever is on infra on-call duty, this shortens the first step of an investigation: instead of opening five charts and manually cross-referencing a drop in cache hit ratio with an I/O spike, you ask for a summary and start from there to validate the hypothesis.

One technical caveat is worth making: pg_statviz remains an aggregate telemetry instrument, not a substitute for EXPLAIN (ANALYZE, BUFFERS) on a specific query. AI analysis helps point in a direction ("vacuum is lagging on this table," "the buffer cache dropped after this time"), but the execution plan for the problematic query is still the document that decides whether the right index exists or not. Treating the model's explanation as a final verdict, without opening the actual plan, is the mistake any experienced DBA avoids.

What Remains Open: Sensitive Data and Trust in the Model

Sending production database statistics to an external API raises a question the post doesn't resolve: exactly what data leaves the environment when you choose Claude, GPT, or Gemini instead of local Ollama? pg_stat_* statistics don't contain business data rows, but they do reveal table names, volume, load patterns, and, in some cases, query text from pg_stat_statements if the integration ends up using that view.

Teams with stricter data policies at least have the option of running everything locally with Ollama, which Gündüz packages with his own build ("ours") on RHEL 9, RHEL 10, Amazon Linux 2023, and SLES 16; on Fedora, the distro maintains its own SDKs.

The other reservation is the usual one with automated analysis: a language model can misread a chart, invent cause and effect that the numbers don't support, or simply overgeneralize. No automated test in the packaging pipeline covers the quality of the responses; Gündüz himself states that real API calls were tested manually, by him, on a Fedora 44, not across every distro and provider combination. The textual explanation is a reading shortcut, not a performance audit.

Installation and What's Still Missing

For those administering RPM, installation follows the normal PGDG repository flow, with two specific gotchas:

• On RHEL 9, you need to enable the CRB and EPEL repositories before installing pg_statviz, because part of the python3 dependency stack comes from there.
• On SLES, anyone who already has the distro's own python313-ollama package may need to run zypper install --allow-vendor-change for the PGDG version to take precedence over the native one.

The next obstacle has already been identified: the openai 3.x series requires httpx2, a newer anyio, and typing-extensions 4.14, so the package stays locked at 2.28.0 for now. Gündüz is also considering turning the AI dependencies into weak Recommends in the RPM, so that anyone who never uses pg_statviz analyze with a language model doesn't need to download four entire SDKs just to generate the traditional charts. It's a small packaging decision, but one that sums up well the spirit of the work described in the post: the AI functionality is optional, and the cost of keeping it available shouldn't fall on those who just want the usual pg_statviz.

Source: Devrim Gündüz, "PostgreSQL RPM repository meets AI with pg_statviz," Planet PostgreSQL (https://postgr.es/p/9xN).