PostgreSQL 19 é adiado para 19 de novembro após revisão com IA achar cerca de 40 defeitos

O PostgreSQL 19 foi adiado para 19 de novembro de 2026, depois que a revisão de código assistida por modelos de linguagem passou a apontar defeitos mais rápido do que os desenvolvedores conseguem corrigir. O lançamento estava previsto para o fim de setembro ou início de outubro, a lista de problemas chegou a cerca de 40 relatórios de defeito — a maioria em casos de borda — e de 8 a 10 recursos foram retirados da versão, segundo reportagem do site The Register publicada em 16 de outubro.

Para quem mantém PostgreSQL em produção no Brasil e já tinha migração marcada para o fim do ano, o atraso deixa de ser notícia de comunidade e vira questão de cronograma: a data nova cai a um mês e meio do fechamento de 2026.

O que a revisão de código com IA mudou no ciclo do PostgreSQL 19

Mudou a velocidade com que os defeitos aparecem, não a qualidade do código que já estava escrito. Peter Eisentraut, vice-presidente da EDB e committer do projeto, descreveu ao The Register o efeito das novas ferramentas: com revisão assistida por LLM, esse tipo de problema surge muito mais rápido, e a equipe acaba diante de uma lista de cerca de quarenta relatórios de defeito. Segundo ele, a régua de qualidade efetiva subiu depois do momento em que os recursos foram escritos e integrados.

Eisentraut faz questão de separar a causa. De acordo com ele, não se trata de código malfeito nem de "vibe coding": a técnica não estava disponível quando a maior parte dos recursos foi escrita, antes de a revisão por LLM ficar boa o suficiente para encontrar essas falhas. A expectativa dele é que a situação se normalize nos próximos ciclos, quando o código novo já nascer sob esse tipo de análise.

O caso não é isolado dentro do projeto. Levantamento publicado em 16 de setembro de 2026 por Elizabeth Garrett Christensen, developer advocate da Snowflake, contou 53 reversões no ciclo da versão 19 e já projetava atraso de semanas ou meses. O texto registra que várias pessoas no projeto estão usando ferramentas de IA para achar bugs e produzir casos de teste reproduzíveis, e menciona um "concurso de bugs assustadores" conduzido por Robert Haas com apoio de código de IA para identificar recursos em risco.

Quais recursos saíram do PostgreSQL 19 e quais ficaram

O corte mais sensível é o suporte a SQL Property Graph Queries, o SQL/PGQ, que permite consultar dados relacionais como se fossem um grafo e entrou no padrão SQL em 2023. Foi retirado por problemas de arquitetura não resolvidos. O veterano Tom Lane, segundo o The Register, disse que apostaria um jantar que, se o recurso fosse entregue na 19, apareceriam bugs pós-lançamento impossíveis de corrigir antes da versão 20.

A lista de reversões levantada pela Snowflake inclui ainda ALTER TABLE MERGE/SPLIT PARTITION, UPDATE/DELETE FOR PORTION OF, GROUP BY ALL, a mudança da compressão TOAST padrão para lz4, formatos não textuais de saída no pg_dumpall, rastreamento de consultas aninhadas no pg_stat_statements e checksums de dados on-line. Os recursos retirados devem voltar no PostgreSQL 20.

Entre o que ficou, o destaque é o REPACK CONCURRENTLY, que recupera espaço em disco sem travar a tabela durante a operação — hoje esse trabalho exige janela de manutenção em bancos grandes.

O que muda para equipes brasileiras

Quem planejava subir a versão 19 ainda em 2026 ganha quase dois meses a mais de espera e precisa refazer o cronograma de testes e homologação. Projetos que contavam com SQL/PGQ ou com as mudanças de particionamento têm de considerar que esses recursos ficaram para o ciclo seguinte, cuja data não está definida. Vale conferir as notas de versão oficiais antes de fechar qualquer plano de migração, já que a lista pode mudar até o lançamento.

Para times que estão adotando revisão automática de código, o caso serve de leitura prática: a ferramenta não produz entrega mais rápida no primeiro momento. Ela expõe de uma vez o passivo acumulado antes da adoção, e esse passivo precisa de gente para triar e corrigir. No PostgreSQL, um projeto maduro e com processo de revisão humana rigoroso, o resultado foi adiar o lançamento em vez de entregar com defeitos conhecidos.