Postgres reescrito em Rust, agora passando 100% dos testes de regressão do Postgres
Um projeto que usa grandes modelos de linguagem para reescrever a base de código C do PostgreSQL em Rust e agora passa 100% dos testes de regressão do PostgreSQL está provocando debate sobre o que isso realmente prova. Os comentaristas ponderam os benefícios potenciais — segurança de memória, nova arquitetura de threads e ganhos de desempenho alegados — contra preocupações sérias com casos extremos não testados, dependência de conjuntos de testes existentes em vez de “cicatrizes de produção”, legibilidade de código gerado por LLMs e manutenção de longo prazo. As escolhas de licenciamento (AGPL em cima de um original com licença permissiva) e a tendência mais ampla de “reescreva em Rust com IA” também levantam questões sobre confiança, adoção pela comunidade e o futuro do desenvolvimento de código aberto.
IA vs. Reescritas “Reais”
- Muitos querem uma distinção clara entre reescritas conduzidas por IA e reescritas humanas; outros argumentam que qualidade e verificação importam mais do que a autoria.
- Alguns veem “reescrever em Rust usando LLMs” como um projeto meme ou de vibe, muitas vezes feito rapidamente por uma única pessoa sem um plano de manutenção de longo prazo.
- Outros veem isso como uma importante prova de conceito mostrando o quão baratos os portos de linguagem em larga escala se tornaram, potencialmente permitindo modernização (por exemplo, sistemas da era COBOL).
Testes, Confiabilidade e “Cicatrizes de Produção”
- Passar em 100% dos testes de regressão do Postgres é considerado impressionante, mas muitos enfatizam que isso só prova a ausência de regressões conhecidas.
- Preocupações recorrentes:
- A confiabilidade real vem de anos de incidentes em produção e “cicatrizes”, não apenas de testes.
- Os testes não cobrem todos os caminhos de sucesso, casos extremos de concorrência ou cantos de desempenho.
- É possível ajustar demais para os testes, especialmente para LLMs.
- Alguns sugerem testes diferenciais (executar ambos os bancos e comparar saídas), testes baseados em propriedades, fuzzing, testes no estilo Jepsen e mineração de relatórios de bugs para criar novos testes.
Rust, Segurança de Memória e Desempenho
- Defensores: o modelo de segurança do Rust e uma arquitetura de uma thread por conexão poderiam simplificar os internals, reduzir a complexidade da memória compartilhada e desbloquear melhor paralelismo.
- Críticos: existem milhares de usos de
unsafe(especialmente no parser), então muitos riscos no estilo C continuam; alguns perguntam “por que Rust afinal” se ele é tão inseguro. - Alegações do autor do projeto:
- A versão publicada atual é cerca de 8× mais lenta que o Postgres.
- Uma nova versão, ainda não lançada, é cerca de 50% mais rápida em cargas transacionais e cerca de 300× mais rápida em cargas analíticas, com armazenamento colunar e execução em lotes, cerca de 2× mais lenta que o ClickHouse no clickbench.
Licenciamento e Legalidade
- O port é AGPL; alguns não gostam da mudança de uma licença permissiva do Postgres para copyleft.
- Há debate sobre se traduções geradas por LLM são obras derivadas, obras novas ou até mesmo protegíveis por copyright; o consenso no tópico é que é “juridicamente nebuloso”, mas o upstream permissivo provavelmente permite um empacotamento mais restritivo.
Manutenção, Confiança e Uso em Produção
- Muitos veem isso como um experimento interessante ou ferramenta de aprendizado, não algo para rodar em produção “por anos” ainda.
- Preocupações com:
- Ônus de pessoa única.
- Revisabilidade de milhares de commits gerados por IA.
- Comunidade de longo prazo, ecossistema de extensões e upgrades compatíveis com versões anteriores.
- Alguns propõem um uso positivo: executar essas reescritas contra cargas reais para descobrir testes ausentes e devolver melhorias ao Postgres upstream.