PGConf.EU 2026: Postgres ganha radar e radar-analyst, dupla open source para diagnóstico sem agente residente

Na PGConf.EU 2026, em Valencia, o especialista Jimmy Angelakos apresentou radar e radar-analyst, que tiram uma fotografia completa do banco sem exigir agente rodando, e detalhou o pg_statviz, que guarda séries temporais dentro do próprio Postgres↳PostgreSQL11 conteúdosPostgreSQL via SSL com GolangData · abr 20195 itens legais sobre data types do PostgreSQLData · mar 20195 serviços gratuitos na cloud para bancos de dados PostgresData · fev 2025Ver tudo em Data →.

A PostgreSQL Conference Europe 2026 aconteceu de 20 a 23 de outubro, no Palacio de Congresos de Valencia, e reuniu a comunidade europeia de Postgres em torno de palestras, painéis e eventos de comunidade. Entre os participantes estava Jimmy Angelakos, que relatou em seu blog, no Planet PostgreSQL, uma semana cheia: um painel sobre incidentes em produção, uma palestra técnica, uma sessão de autógrafos e três eventos de comunidade no mesmo dia.

Para quem constrói e mantém sistemas em produção no Brasil, duas apresentações de Angelakos interessam diretamente: o par de ferramentas radar e radar-analyst, e o projeto pg_statviz. radar e radar-analyst são software aberto sob a licença PostgreSQL; pg_statviz também é um projeto aberto. As três endereçam um problema recorrente: diagnosticar um banco depois que o incidente já aconteceu, sem precisar de um agente de monitoramento que já estivesse de prontidão.

O problema do agente que não estava rodando

Quem já atendeu chamado de produção conhece o cenário. Um agente de monitoramento só ajuda se já estava ativo antes do problema começar. O log do Postgres mostra só o que as queries fizeram, não o estado do sistema operacional nem a configuração vigente. E o resto da investigação vira uma troca de e-mails pedindo print disso, saída daquele comando, versão de tal parâmetro.

radar ataca esse ponto específico: é um binário Go↳Go23 conteúdosEntendendo o Green Tea GC do Go 1.26Dev (Back & Front) · mai 2026Função recursiva em Go para acessar valores em mapas aninhadosDev (Back & Front) · set 2025Publicando projeto desenvolvido em Golang em um server grátisDev (Back & Front) · mar 2025Ver tudo em Dev (Back & Front) → estático único que coleta, em segundos, uma fotografia do PostgreSQL e do host em um único arquivo zip, e então encerra a execução. Ele não captura dados de linha nem senhas, apenas metadados: catálogos do sistema, estatísticas acumuladas e configuração. Isso resolve o problema de distribuição (não precisa instalar nada permanente) sem abrir mão da superfície de dados sensível a vazamento.

radar-analyst é a segunda metade do par, e é o que transforma o zip em diagnóstico. A ferramenta roda um conjunto determinístico de regras sobre o arquivo coletado, atribui um veredito a cada categoria avaliada e associa cada achado a uma correção sugerida. 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 → pode, opcionalmente, redigir um resumo em cima disso, como faria um DBA sênior ao explicar o relatório, mas Angelakos foi categórico num ponto da apresentação: só as regras determinísticas podem criar um achado, e o modelo nunca pode suavizar o veredito que elas já definiram.

Essa separação importa mais do que parece. Em ferramentas de diagnóstico assistidas por IA, o risco clássico é o modelo "amaciar" um problema real para soar mais ameno no resumo, ou inventar uma causa plausível que não está nos dados. Ao travar a camada de veredito nas regras e deixar a IA apenas narrar, radar-analyst evita esse tipo de alucinação onde ela mais doeria: no relatório que vai para o gestor decidir se escala o incidente.

pg_statviz: série temporal sem exportador externo

A segunda ferramenta detalhada por Angelakos, no PostgreSQL Observability Summit do dia de eventos de comunidade (sexta-feira da conferência), ataca um problema diferente: observabilidade↳Observabilidade11 conteúdosObservabilidade para APIs: os desafios e benefícios dessa abordagemDev (Back & Front) · jan 2025Falhas em Observabilidade afetam os Apps e a Segurança das OrganizaçõesDev (Back & Front) · nov 2023ADK Java 1.0: O Google quer que você pare de gambiarra Python no seu backendMarketing Tech · abr 2026Ver tudo em DevSecOps → contínua, não snapshot pontual. pg_statviz aproveita as estatísticas cumulativas que o próprio PostgreSQL já mantém internamente e as grava em tabelas dentro do mesmo banco monitorado, transformando-as em séries temporais que podem ser consultadas e visualizadas sem um agente externo ou um exportador rodando ao lado.

A lógica é parecida com a de radar-analyst na parte de IA: a camada opcional entrega os gráficos gerados, como imagem, a um modelo de linguagem com capacidade de visão, porque, segundo Angelakos, "o gráfico é o que um DBA de fato lê" quando investiga uma tendência de degradação. De novo, as regras determinísticas têm a palavra final sobre o veredito; a IA só lê e comenta o que já foi calculado.

Para equipes que hoje dependem de pilhas de observabilidade externas (Prometheus com exporter, Datadog, New Relic) para acompanhar métricas de Postgres, pg_statviz não é substituto de monitoramento de infraestrutura completo. Ele serve a um caso mais estreito: times pequenos, ambientes isolados ou bancos onde instalar e manter um agente externo é operacionalmente custoso, mas que ainda querem histórico de métricas internas do banco sem sair do próprio Postgres.

Quando cada ferramenta faz sentido, e quando não

A tabela abaixo resume o recorte de uso de cada abordagem, com base no que foi apresentado na conferência:

Nenhuma das duas ferramentas de Angelakos substitui uma pilha de observabilidade madura. O valor delas está em cobrir a lacuna entre "não tenho nada monitorando" e "preciso entender o que aconteceu agora", que é exatamente a situação em que boa parte dos times brasileiros se encontra quando o Postgres de produção apresenta um problema sem aviso prévio.

O que o painel de confissões já deixava claro

Na terça-feira da conferência, Angelakos participou do painel Postgres On-Call Confessions: Worst Practices 101, ao lado de Ants Aasma, Mayuresh Bagayatkar, Hettie Dombrovskaya, Pavlo Golub e Teresa Lopes. A proposta era simples: reunir os "consertos óbvios" que, na prática, pioraram um incidente de produção, e abrir o microfone para a plateia confessar os próprios.

O padrão que emerge desse tipo de painel, recorrente em conferências de Postgres, é sempre o mesmo: a correção aplicada sob pressão, sem entender o plano de execução por trás do sintoma, costuma trocar um problema visível por um problema silencioso. É o pano de fundo que justifica ferramentas como radar-analyst: regras determinísticas, aplicadas de forma consistente, tendem a errar menos do que um DBA cansado decidindo às três da manhã se reinicia o servidor ou mata a query.

Onboarding: o obstáculo que ninguém tinha medido

Um achado paralelo, menos técnico mas relevante para quem treina gente nova em Postgres no Brasil, veio do PostgreSQL Training Materials Working Group, conduzido por Angelakos e Hettie Dombrovskaya na sexta-feira. O grupo fez uma demonstração ao vivo do site postgresql.org do ponto de vista de um iniciante total, e o resultado não foi favorável ao site oficial.

Em resumo: o grupo contou 14 cliques até encontrar por onde começar, mais 7 cliques na página de download até chegar a algo copiável no Linux, sem detecção automática de sistema operacional, sem sandbox para quem tem o notebook travado por política corporativa, o primeiro psql falha por causa do pg_hba.conf, e em seguida o iniciante é instruído a criar um banco sem receber explicação do porquê. O grupo concluiu que não é preciso criar material novo do zero: já existe tutorial oficial, cursos de terceiros, sites de exercício e sandboxes suficientes, bastando organizar e linkar o que já existe num fluxo de onboarding coerente.

Para quem forma equipe júnior ou dá treinamento interno de Postgres, esse mapeamento é um atalho útil: em vez de escrever um tutorial próprio do zero, vale revisar o material já existente com o mesmo olhar crítico do grupo de trabalho antes de indicar qualquer link ao time novo.

O que muda na prática

Nenhuma das ferramentas apresentadas resolve o trabalho de modelagem e integridade que continua sendo a base de qualquer banco saudável, e isso Angelakos não prometeu resolver. O que radar, radar-analyst e pg_statviz endereçam é a distância entre "algo deu errado" e "sei exatamente o que corrigir", sem depender de uma pilha de observabilidade já instalada quando o problema aparece.

Para equipes brasileiras que operam Postgres sem um DBA dedicado em tempo integral, a combinação é um ponto de partida de baixo custo: radar como ferramenta de emergência, para rodar e enviar no momento do chamado, e pg_statviz como histórico leve de estatísticas internas enquanto a equipe não investe numa pilha de observabilidade completa. A ressalva que vale repetir é a mesma que Angelakos fez questão de frisar nas duas apresentações: a IA opcional narra, mas quem decide o veredito continua sendo a regra determinística escrita por quem entende o Postgres por dentro.

Fonte: Planet PostgreSQL