Postgres 19 atrasou: a IA está achando bugs demais

O Postgres 19 era para ter saído em setembro, como quase todo major do projeto, e ainda não saiu. O motivo é curioso: não falta código, sobra bug. Robert Haas, um dos committers mais antigos do PostgreSQL, escreveu um post com um título sem rodeio: Postgres 19 is late, and it's AI's fault. Segundo ele, ferramentas de IA estão encontrando problemas num ritmo que a comunidade nunca tinha visto, e isso empurrou o calendário.

Vale parar um minuto nessa notícia. Ela diz muito sobre o Postgres 19, mas diz ainda mais sobre como software vai ser feito daqui pra frente.

Por que o Postgres 19 atrasou?

O ciclo do Postgres é bem previsível. Feature freeze em abril, betas no meio do ano, release candidate e lançamento lá por setembro. O Postgres 17 saiu em setembro de 2024. O 18 saiu em setembro de 2025. Dá para planejar upgrade em cima disso.

Em 2026 a engrenagem travou na fase de estabilização. É nessa fase que o pessoal testa o que entrou no freeze e corrige o que aparece. O problema é que agora aparece muito mais coisa.

Pesquisadores e contribuidores passaram a apontar modelos de IA para o código-fonte do Postgres. Eles leem o C, procuram caminhos estranhos, geram casos de teste e reportam. Uma parte é ruído. Mas uma parte relevante é bug de verdade: condição de corrida, erro de borda em tratamento de memória, comportamento errado em combinação rara de features.

E o Postgres tem uma política que eu respeito muito: bug conhecido em feature nova não vai para release. Se não dá para corrigir com segurança, a feature sai ou o lançamento espera.

O gargalo não é achar bug, é corrigir

Aqui está o ponto que eu acho mais interessante. Achar bug ficou barato. Corrigir continua caro.

Para cada relatório, alguém precisa:

• reproduzir o problema
• entender se é bug real ou falso positivo
• escrever o patch
• revisar o patch (no Postgres, isso é sério)
• garantir que a correção não quebra outra coisa

Nenhuma dessas etapas ficou dez vezes mais rápida. A primeira etapa ficou. O resultado é uma fila crescendo do lado de quem tem permissão de commit, que é um grupo pequeno de gente muito experiente.

Achar bug virou commodity. Revisar continua sendo artesanato.

Quem já foi responsável por um repositório popular conhece a sensação. Você abre o GitHub de manhã e tem 40 issues novas. Metade é duplicada, umas cinco são reais e graves. Agora imagine isso num banco de dados que roda o financeiro de meio mundo, onde um patch errado vira corrupção de dados em produção.

Isso é bom ou ruim?

Minha opinião forte: é bom. Muito bom, até.

Esses bugs já estavam lá. A IA não criou nenhum deles. Ela só acendeu a luz num cômodo que estava escuro. A alternativa era você descobrir o mesmo bug às três da manhã, com o banco travado e o Slack pegando fogo.

Um atraso de algumas semanas, ou de alguns meses, num banco que vai rodar no seu servidor por cinco anos é um preço baixo. Eu prefiro mil vezes um Postgres 19 atrasado a um 19.0 que exige um 19.1 de emergência duas semanas depois.

Tem um lado menos bonito, claro. O custo dessa limpeza cai em cima de voluntários e de engenheiros pagos por poucas empresas. Gerar relatório automatizado custa centavos. Analisar cada um custa horas de alguém que poderia estar escrevendo feature. Se a comunidade não criar filtros, o risco é o mantenedor esgotar antes do bug acabar.

E isso não é exclusivo do Postgres. curl, Linux, OpenSSL e vários outros projetos já reclamaram de relatórios gerados por IA de baixa qualidade. A diferença aqui é que boa parte dos achados parece ser legítima. O problema não é lixo, é volume.

O que muda no seu upgrade de Postgres

Na prática, para quem usa Postgres no dia a dia, o recado é simples.

Não planeje upgrade pela data do calendário. Se o seu time tinha "migrar para o 19 no Q4" no roadmap, reveja. Espere o lançamento, e de preferência espere o primeiro minor. Isso sempre foi boa prática, agora é ainda mais.

Teste o beta ou o RC no seu workload. Ninguém conhece suas queries melhor que você. Suba um container e rode sua suíte contra ele:

docker run -d --name pg19 -e POSTGRES_PASSWORD=dev -p 5433:5432 postgres:19rc1
DATABASE_URL=postgres://postgres:dev@localhost:5433/postgres bun test

Ajuste a tag para a versão de teste que estiver publicada. Se algo quebrar, reporte. Seu relatório com reprodução real vale mais que dez relatórios genéricos.

Fique de olho nos minors das versões atuais. Muitos desses bugs não estão só no código novo. Quando a correção afeta versões antigas, ela é portada para os minors do 14 ao 18. Então é bem provável que os próximos releases de manutenção venham mais recheados que o normal. Atualizar minor é barato e geralmente não exige pg_upgrade:

SELECT version();
-- PostgreSQL 18.1 ... então confira se já existe 18.x mais novo

Se você usa banco gerenciado (RDS, Neon, Supabase, Cloud SQL), o minor costuma chegar sozinho na janela de manutenção. Só confirme que a janela está configurada e não foi esquecida em 2022.

O que isso ensina para o seu próprio código

Dá para tirar uma lição que vale para qualquer projeto, inclusive aquela API em Node que você mantém sozinho.

Se ferramentas de IA conseguem achar bug no Postgres, um dos códigos mais revisados do open source, elas vão achar no seu. Isso funciona para os dois lados. Você pode usar a seu favor antes do lançamento, ou alguém pode usar contra você depois.

O que eu tenho feito nos meus projetos:

• rodar revisão automatizada em PR, mas tratar a saída como sugestão, nunca como verdade
• pedir para a ferramenta gerar o teste que reproduz o bug, não só a descrição dele
• só aceitar um achado depois que o teste falha de verdade na minha máquina

Esse último ponto resolve boa parte do ruído. Relatório sem reprodução vai para o fim da fila. Relatório com teste falhando vira prioridade. É exatamente o filtro que um mantenedor sobrecarregado precisa.

A outra lição é sobre capacidade. Se sua equipe começar a usar IA para revisar código, o número de problemas encontrados vai subir. Isso não significa que o código piorou. Significa que você vai precisar de tempo no sprint para corrigir. Quem não reserva esse tempo cria uma pilha de issues que ninguém olha, e aí a ferramenta vira só mais um alarme ignorado.

Vale esperar pelo Postgres 19?

Vale. E a espera em si é um bom sinal.

O Postgres ganhou a reputação de banco que não te deixa na mão justamente por escolhas assim: segurar o lançamento em vez de empurrar código com bug conhecido. A IA mudou o ritmo da caça, mas a cultura de revisão continua a mesma. Para quem guarda dado de cliente, é exatamente isso que eu quero de um banco.

O lado engraçado é que, depois de anos ouvindo que a IA ia escrever todo o software do mundo, a primeira grande contribuição dela ao Postgres foi dar mais trabalho para os humanos. Pelo menos é trabalho do tipo certo.

Eu uso Postgres em praticamente tudo que construo, e vou esperar o 19 com calma. Se quiser ver onde ele roda por aqui, dá uma olhada nos meus projetos.

O Postgres 19 atrasou, e o motivo não é falta de código. É bug demais.

Ferramentas de IA estão encontrando problemas no código do Postgres num ritmo que a comunidade nunca tinha visto. E como o projeto não lança feature com bug conhecido, o calendário foi pro espaço.

O que mais me chamou atenção: achar bug ficou barato, corrigir continua caro. Reproduzir, revisar e garantir que nada quebrou ainda depende de um grupo pequeno de gente muito experiente.

Pra mim é uma ótima notícia. Esses bugs já estavam lá. A IA só acendeu a luz antes de eles aparecerem às três da manhã no seu servidor de produção.

Se o seu time começar a usar IA pra revisar código, reserve tempo no sprint pra corrigir o que ela encontrar. Senão vira só mais um alarme que ninguém olha.

Escrevi sobre o que isso muda no seu upgrade e no seu próprio código. O link está nos comentários.

#PostgreSQL #InteligenciaArtificial #OpenSource #DesenvolvimentoDeSoftware #Backend