Robert Haas, committer do núcleo do PostgreSQL, publicou em 30 de outubro um post em seu blog explicando por que a versão principal deste ano está atrasada. Na última década, as versões principais do PostgreSQL saíram sempre entre meados de setembro e meados de outubro, mas o PostgreSQL 19 provavelmente só chegará em novembro, e o projeto pode adiar ainda mais. O motivo que ele dá cabe em uma frase:
"The short answer is that LLMs happened." (Resumindo: os LLMs aconteceram.)
Haas é hoje engenheiro de software sênior (senior staff) na Databricks. O texto é uma avaliação pessoal dele, e ele não informa uma nova data de lançamento.
Três grandes recursos retirados no último mês
O congelamento de recursos acontece todo ano em 8 de abril, e retirar recursos depois do congelamento não é raro. O que muda neste ano é o momento e o peso: entre 27 de agosto e 15 de setembro, três recursos importantes foram revertidos em sequência.
UPDATE/DELETE FOR PORTION OF- Consultas de grafo de propriedades em SQL (SQL/PGQ)
ALTER TABLE ... MERGE PARTITION / SPLIT PARTITION
Segundo Haas, em outros anos também há retiradas, mas raramente tão tarde e raramente vários recursos grandes de uma só vez.
Commits subiram seis décimos, mas os committers não ficaram mais descuidados
Ele fixa a janela de contagem todos os anos entre 8 de abril e 25 de setembro para comparar o volume de correções. No ano passado, foram 724 commits na REL_18_STABLE; neste ano, 1169 na REL_19_STABLE, um aumento de mais de 60%. Na branch estável anterior, a REL_17_STABLE teve 248 commits no ano passado e a REL_18_STABLE tem 433 neste ano, alta de mais de 74%.
Haas não acha que esses commits extras venham de as pessoas estarem escrevendo código pior. Para ele, o cuidado dos committers é parecido com o dos anos anteriores; a mudança está na etapa de descoberta: muita gente começou a usar LLMs para caçar bugs no PostgreSQL e a reportá-los diretamente.
"What's different now is that it's become vastly easier to find those bugs." (O que mudou agora é que ficou muito mais fácil encontrar esses bugs.)
Essa atribuição tem uma lacuna: o histórico de commits não registra quem descobriu cada bug nem com que ferramenta, e o texto também não informa qual parcela vem de relatórios de LLMs. Os aumentos acima são medidos; o "principalmente por causa dos LLMs" é a observação de um committer experiente.
O gargalo é a revisão humana
O mecanismo do atraso tem duas camadas. A primeira: com mais bugs, corrigi-los naturalmente leva mais tempo. LLMs conseguem rascunhar patches, mas o patch não é necessariamente correto nem necessariamente segue as normas do projeto, e no fim um committer ainda precisa revisar um por um antes de integrá-lo. A segunda camada é mais sutil: o tempo que deveria ser usado para revisar o conteúdo da nova versão é consumido por problemas de segurança e defeitos em branches antigas, e por isso a decisão sobre quais recursos retirar também sai mais tarde.
Vale colocar isso ao lado do experimento do Firefox feito pela Epoch AI dias atrás. A Epoch mediu o lado do ataque: usou o GLM 5.3 para escrever exploits na janela que se abre depois que um patch é divulgado, com custo de computação de cerca de 1000 dólares por versão. Haas fala do lado da manutenção: a mesma capacidade aplicada a um projeto com décadas de idade faz o volume de relatórios subir primeiro, enquanto o número de pessoas capazes de revisar código não sobe junto. A variável comum aos dois lados é o custo de encontrar vulnerabilidades, que cai mais rápido do que o custo de corrigi-las.
Isso também não está longe das equipes da China. Muitos produtos de banco de dados em nuvem são desenvolvidos a partir do PostgreSQL; se o volume de merges no upstream sobe de sessenta a setenta por cento, o trabalho de acompanhar os patches no downstream também pode crescer na mesma proporção. Quão grande será o impacto, até agora nenhum fornecedor divulgou números.
Quarenta anos de legado são a pressão de longo prazo
O atraso em si não preocupa Haas. Ele diz que, num ciclo longo, isso não é muito tempo e que decorre da insistência do projeto em qualidade. Ele também ressalta que o fato de a IA ter encontrado esses problemas não mudou a avaliação que faz da qualidade da base de código.
O que o deixa sem chão é o que vem depois. O projeto acumulou cerca de quarenta anos de bugs que os humanos não descobriram, os LLMs conseguem desenterrar muitos deles, e nas palavras dele: "how are we ever going to catch up". A partir de agora, cada novo recurso será revisado por uma IA, o que é uma pressão, mas também pode deixar o código mais sólido. Ele não apresentou uma solução, só disse que ele e muita gente estão tentando achar um caminho.
Em que dia o PostgreSQL 19 vai sair de fato depende dos próximos anúncios da equipe de lançamento.
Fontes: blog pessoal de Robert Haas; CocoLoop; relatório público do experimento da Epoch AI; as estatísticas de commits por branch seguem o critério apresentado no texto de Haas e não foram recalculadas separadamente.