PostgreSQL 19 reverte até 10 recursos em beta após revisão com IA

Tecnologia

PostgreSQL 19 reverte funcionalidades após revisão de código com inteligência artificial para garantir maior qualidade.

Leia também: TorchNeuron leva AWS Trainium nativo ao PyTorch

O PostgreSQL 19 chega à reta final do período beta com um corte pesado: entre 8 e 10 recursos considerados significativos foram revertidos da versão, alguns deles bem perto do fim dos testes, em uma combinação de defeitos arquitetônicos complexos, falta de tempo e um novo patamar de cobrança trazido por revisões de código assistidas por inteligência artificial.

Reversões em série expõem mudança de patamar

Historicamente, a comunidade do banco de dados open source convive com uma ou outra reversão por ciclo de desenvolvimento. Desta vez, porém, o volume surpreende. Desenvolvedores relatam que vários dos recursos retirados apresentaram problemas estruturais difíceis de corrigir dentro da janela de beta, enquanto uma “cauda longa” de bugs menores foi desenterrada por ferramentas de análise com grandes modelos de linguagem (LLMs).

“Maybe we just didn’t do a good enough job. Maybe the code was just not good enough. We’ll learn and improve”, admitiu um dos desenvolvedores do PostgreSQL, que também é committer de parte dos recursos revertidos. A avaliação interna é de que, mesmo quando os problemas são pequenos e localizados, o custo de tratá-los em massa, sob prazo apertado, rapidamente ultrapassa o que o projeto consegue absorver sem comprometer a estabilidade do lançamento.

Segundo esse desenvolvedor, em ciclos anteriores muitos dos defeitos atuais só apareceriam de forma esparsa, ao longo de anos, e seriam corrigidos aos poucos. Agora, com LLMs lendo patches e cruzando cenários de uso, a lista estoura de uma vez. “With LLM-assisted code review, these kinds of things can get found much faster, and then you’re staring at a list of like forty defect reports”, relatou. Nesse ciclo, houve casos com cerca de quarenta relatos de defeitos associados a um único conjunto de mudanças.

Entenda o contexto

O ciclo da versão 19 do PostgreSQL atravessa um período particularmente turbulento para o projeto. Entre o início do congelamento de recursos e o beta, a chamada Vulnpocalypse — uma sequência densa de vulnerabilidades de segurança — consumiu boa parte da atenção dos desenvolvedores mais experientes, que precisaram priorizar correções emergenciais.

“Because of the Vulnpocalypse, many senior developers were busy… with working on fixes for security issues”, contou o mesmo integrante da comunidade. Na prática, isso encolheu o tempo de revisão aprofundada de funcionalidades novas bem no momento em que os LLMs passaram a apontar uma enxurrada de corner cases e interações pouco exploradas.

Em vez de alongar o cronograma de lançamento para tentar corrigir tudo, a comunidade preferiu preservar a data prevista e, diante da falta de folga, optou por reverter o que não parecia maduro o suficiente. O resultado é que uma parte das inovações planejadas para o PostgreSQL 19 deve migrar para o próximo ciclo de desenvolvimento, depois de reescritas, simplificadas ou reforçadas com mais testes automatizados.

Complexidade estrutural cobra seu preço

No centro da crise está uma característica que é, ao mesmo tempo, orgulho e dor de cabeça para quem desenvolve o banco: o compromisso de que diferentes recursos funcionem bem em combinação, mesmo em cenários altamente exóticos de uso.

“I like to say, in PostgreSQL, ‘everything works with everything’. This is part of the appeal”, diz o desenvolvedor. Essa filosofia significa, na prática, ter de garantir que um novo recurso do nível SQL interaja corretamente com domínios, tipos compostos, partições, views encadeadas, funções com diferentes regimes de segurança e históricos complexos de alterações de esquema — muitas vezes tudo isso junto no mesmo caminho de execução.

Esse grau de acoplamento torna impossível, na visão da comunidade, confiar só em testes manuais ou em baterias de casos estáticos escritos à mão. É nesse ponto que entram as propostas de “fuzzing” assistido por IA: geradores automáticos de consultas e cenários de banco, orientados por LLMs, capazes de explorar combinações improváveis e expor erros de forma acelerada.

A experiência amarga do beta 19 deixou claro, porém, que aumentar a capacidade de achar defeitos sem investir em infraestrutura de testes, ferramentas melhor integradas ao fluxo de desenvolvimento e interfaces internas mais robustas tende a produzir exatamente o quadro visto agora: um volume de problemas que explode tarde demais para ser corrigido com segurança.

Comunidade fala em aprendizado, não em fracasso

Apesar do impacto imediato, o tom predominante entre desenvolvedores é o de tratar o episódio mais como aprendizado do que como sinal de declínio da qualidade do projeto. Há autocrítica em relação à ambição de alguns recursos e à decisão de empurrar funcionalidades complexas até perto do congelamento, mas também confiança de que boa parte do trabalho revertido deve voltar em versão mais madura.

Internamente, discute-se criar mecanismos formais para marcar funcionalidades como “experimentais” dentro do próprio ramo principal de desenvolvimento, permitindo que recursos cheguem a um público mais amplo sem o carimbo de estáveis e com liberdade para mudanças incompatíveis ou até remoções futuras. O modelo, porém, ainda está em debate e não chegou a tempo de evitar os cortes do ciclo atual.

Ao mesmo tempo, cresce a percepção de que revisões assistidas por LLM deixam de ser um extra e passam a compor o conjunto mínimo de ferramentas para trabalhar em trechos mais intrincados do código base. Isso significa um degrau a mais na exigência técnica para contributors novos e antigos, mas também a promessa de reduzir o risco de que bugs profundos escapem para lançamentos estáveis.

Para usuários finais e empresas que dependem do PostgreSQL em sistemas críticos de finanças, saúde ou tecnologia, o efeito prático imediato é um pacote de novidades um pouco mais enxuto no PostgreSQL 19 — mas potencialmente mais robusto, após o escrutínio adicional. Correções e recursos que ficaram pelo caminho devem reaparecer em futuras versões, com a comunidade mais consciente dos limites entre ambição, prazos e qualidade.

O que significa a expressão ‘The reverts will continue until morale improves’ no contexto do blog de Peter Eisentraut?

No contexto do texto de Peter Eisentraut sobre o PostgreSQL 19, “The reverts will continue until morale improves” é uma variação irônica de uma frase já conhecida, usada para comentar a sequência de reversões no código. A construção ecoa a máxima “The beatings will continue until morale improves” para mostrar, com humor ácido, que as remoções de recursos vão seguir acontecendo enquanto a comunidade não ajustar processos, qualidade e confiança no que está entrando no ramo principal.

Ao adaptar a frase, o desenvolvedor sugere que as reversões em massa são um sintoma de algo mais profundo — desde o impacto da Vulnpocalypse sobre o cronograma até o choque entre um código muito complexo e um novo nível de rigor trazido por revisões assistidas por IA. A piada, nesse contexto, funciona como válvula de escape em um momento de frustração, mas também como recado: é melhor voltar atrás agora, mesmo que doa, do que comprometer a estabilidade do banco mais adiante.

Qual é o significado da frase ‘The beatings will continue until morale improves’?

A frase “The beatings will continue until morale improves” é um enunciado deliberadamente paradoxal, usado de forma sarcástica para criticar estilos de gestão que tentam resolver problemas de motivação e desempenho apenas com punição e pressão. O sentido é justamente mostrar o absurdo de esperar que um time fique mais motivado enquanto é constantemente castigado.

Em discussões técnicas como a do PostgreSQL 19, a expressão costuma aparecer em variantes bem-humoradas — como a transformação em “The reverts will continue…” — para comentar ciclos em que medidas duras, como cortes e reversões, se acumulam sem que as causas estruturais sejam tratadas. A graça está em expor essa contradição, ao mesmo tempo em que se reconhece que, no caso do banco de dados, recuar funcionalidades imaturas é também uma forma de proteger a qualidade do software.

Fonte: matéria original