RPM do PostgreSQL leva pg_statviz com IA a RHEL, SLES e Amazon Linux

Devrim Gündüz, mantenedor dos repositórios PGDG RPM, detalhou como pg_statviz passou a oferecer análise por Claude, GPT, Gemini e Ollama em seis famílias de distribuição Linux↳Linux34 conteúdosKali Linux em um Servidor VPS: como, quando e por que usar?DevSecOps · dez 2024Construindo um Windows Service ou Linux Daemon com Worker Service & .NET Core – Parte 2Dev (Back & Front) · jul 2020Criando uma WebApi utilizando .NET, Linux e VSCodeDev (Back & Front) · ago 2019Ver tudo em DevSecOps →, e por que isso levou três dias de empacotamento.

O que o pg_statviz faz, e o que mudou nele

O pg_statviz é um utilitário leve que tira fotografias periódicas das views internas do PostgreSQL (as pg_stat_*) e transforma essa série histórica em gráficos. Nada disso é novidade em si. O que mudou, segundo o post publicado nesta segunda-feira (12/10) por Devrim Gündüz, mantenedor dos repositórios PGDG RPM e Principal Systems Engineer na EDB, é a camada de análise que versões recentes da ferramenta passaram a oferecer: pegar esses números e pedir a um modelo de linguagem↳LLMs48 conteúdosConsiderações básicas de hardware para modelos de linguagem em código aberto: Memória, Desempenho e ViabilidadeMarketing Tech · out 2025Modelos de linguagem sob ataque: o lado obscuro da IA generativaDevSecOps · mai 2025Criando um LLM – modelo de linguagem de grande escala – do zero com TransformersAI · abr 2024Ver tudo em AI → que os explique em texto corrido.

A notícia concreta não é essa camada em si, já existente, mas a sua disponibilidade. Até a semana passada, o recurso de IA do pg_statviz só funcionava de verdade no Fedora, porque é a única distro que já embute SDKs recentes o suficiente. Com a publicação de sexta-feira (09/10), o comando pg_statviz analyze passa a falar com os quatro provedores (Claude da Anthropic, um modelo Ollama local, OpenAI e Gemini do Google) em toda a matriz de sistemas que o PGDG empacota: Fedora 44+, RHEL 9.8, RHEL 10.1 e 10.2, Amazon Linux 2023, SLES 16.0 e openSUSE Leap 16.0.

O obstáculo era empacotamento, não IA

O problema, como Gündüz descreve, é de descompasso entre dois mundos que evoluem em velocidades diferentes. SDKs de IA (anthropic, openai, google-genai) são lançados toda semana e já exigem pydantic 2 com núcleo em Rust↳Rust7 conteúdosDesmistificando Rust: a linguagem segura e rápida que você precisa conhecerDev (Back & Front) · out 2024Como criar seu primeiro Programa em Rust com Solana PlaygroundDev (Back & Front) · mai 2026Rust no ranking: a segurança de memória perdeu a guerra corporativa?Marketing Tech · abr 2026Ver tudo em Dev (Back & Front) →, httpx2 e metadados de licença no formato PEP 639. Toolchains Python de distribuição enterprise, por outro lado, são congeladas por anos para garantir estabilidade.

O diagnóstico por distro, relatado no post, mostra bem o tamanho do desencontro:

A regra que Gündüz impôs ao trabalho foi não substituir nenhum pacote do sistema operacional: o numpy 1.24 do RHEL 9 continua intacto, porque scipy e os bindings do GDAL dependem dele. A saída, para cada SDK, foi escolher a versão mais nova que ainda compila contra o que a distro já tem, não a mais nova disponível upstream. O resultado é uma matriz de versões deliberadamente desigual: anthropic 0.40.0 em quase tudo, mas openai 2.28.0 no RHEL 9 e Amazon Linux 2023 contra 1.39.0 no RHEL 10 e SLES 16 (este último com um patch de httpx 0.28 aplicado à mão).

Por baixo dos quatro SDKs, Gündüz também teve que empacotar uma pilha nova de dependências pgdg-python3-*: pydantic 2.11.10, pydantic-core, jiter 0.17.0, maturin, httpx, httpcore, anyio, google-auth 2.47.0 e cerca de vinte outros pacotes. As partes em Rust (jiter, maturin, pydantic-core) foram compiladas offline a partir de crates vendorizadas, com scripts mantidos junto das specs no repositório Git do projeto.

Por que isso interessa a quem investiga gargalo, não só a quem empacota

O ângulo que importa para infraestrutura não é a saga de dependências em si, mas o que ela destrava: um time que já roda pg_statviz para acompanhar tendência de uso de recursos agora pode pedir, no mesmo fluxo, que um modelo explique em linguagem natural o que os gráficos de pg_stat_bgwriter, pg_stat_database ou pg_stat_user_tables estão mostrando. Para quem faz plantão de infra, isso reduz o primeiro passo de uma investigação: em vez de abrir cinco gráficos e cruzar manualmente queda de cache hit ratio com pico de I/O, pede-se um resumo e parte-se dali para validar a hipótese.

Vale a ressalva técnica: o pg_statviz continua sendo um instrumento de telemetria agregada, não um substituto para EXPLAIN (ANALYZE, BUFFERS) numa query específica. A análise por IA ajuda a apontar a direção ("o vacuum está atrasado nesta tabela", "o buffer cache caiu depois deste horário"), mas o plano de execução da query problemática continua sendo o documento que decide se o índice certo existe ou não. Tratar a explicação do modelo como veredito final, sem abrir o plano real, é o erro que qualquer DBA experiente evita.

O que fica em aberto: dados sensíveis e confiança no modelo

Enviar estatísticas de um banco de produção para uma API externa levanta uma pergunta que o post não resolve: que dado exatamente sai do ambiente quando se escolhe Claude, GPT ou Gemini em vez do Ollama local? Estatísticas de pg_stat_* não contêm linhas de dado do negócio, mas revelam nomes de tabela, volume, padrão de carga e, em alguns casos, texto de query em pg_stat_statements se a integração chegar a usar essa view.

Times com política de dados mais restritiva têm, pelo menos, a opção de rodar tudo localmente com Ollama, que Gündüz empacota com seu próprio build ("ours") no RHEL 9, RHEL 10, Amazon Linux 2023 e SLES 16; no Fedora, a distro mantém seus próprios SDKs.

A outra reserva é a de sempre com análise automatizada: um modelo de linguagem pode errar a leitura de um gráfico, inventar causa e efeito que os números não sustentam, ou simplesmente generalizar demais. Nenhum teste automatizado do pipeline de empacotamento cobre a qualidade das respostas; o próprio Gündüz afirma que chamadas reais às APIs foram testadas manualmente, por ele, num Fedora 44, não em todas as combinações de distro e provedor. A explicação textual é um atalho de leitura, não uma auditoria de performance.

Instalação e o que ainda falta

Para quem administra RPM, a instalação segue o fluxo normal do repositório PGDG, com duas pegadinhas específicas:

• No RHEL 9, é preciso habilitar os repositórios CRB e EPEL antes de instalar o pg_statviz, porque parte da pilha de dependências python3 vem de lá.
• No SLES, quem já tiver o pacote python313-ollama da própria distro pode precisar rodar zypper install --allow-vendor-change para a versão do PGDG prevalecer sobre a nativa.

O próximo obstáculo já está identificado: a série 3.x do openai exige httpx2, uma anyio mais nova e typing-extensions 4.14, então o pacote fica travado em 2.28.0 por ora. Gündüz também cogita transformar as dependências de IA em Recommends fracos no RPM, para que quem nunca usa pg_statviz analyze com modelo de linguagem não precise baixar quatro SDKs inteiros só para gerar os gráficos tradicionais. É uma decisão de empacotamento pequena, mas que resume bem o espírito do trabalho descrito no post: a funcionalidade de IA é opcional, e o custo de mantê-la disponível não deveria recair sobre quem só quer o pg_statviz de sempre.

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

Fonte: Planet PostgreSQL