Tornando o Postgres 300x mais rápido para analytics: batching, fusão de operadores e SIMD
Uma nova reimplementação do PostgreSQL em Rust, o pgrust, afirma ser até 300x mais rápida em consultas analíticas por meio de execução em lote, fusão de operadores, SIMD e um escalonador redesenhado, e benchmarks iniciais sugerem que ela pode rivalizar ou superar sistemas como o ClickHouse em certas cargas de trabalho. Os comentaristas estão profundamente divididos quanto ao uso intenso de código gerado por IA, à confiabilidade e segurança de um banco de dados de sistemas produzido tão rapidamente e a se verificação formal e fuzzing bastam para confiá-lo em produção. O licenciamento é outro ponto de atrito: a escolha da AGPL é vista por alguns como necessária para impedir que gigantes da nuvem monetizem o trabalho, enquanto outros argumentam que ela bloqueará a adoção corporativa e contribuições, levando a discussões sobre forks ou licenças alternativas.
Licenciamento, Modelo de Negócio e Adoção
- O principal foco do debate é a licença AGPL. Muitos dizem que ela é um “dealbreaker”, especialmente em ambientes corporativos, onde a AGPL é proibida ou fortemente desencorajada, e isso impede o upstreaming para o núcleo do Postgres.
- Defensores argumentam que a AGPL (ou uma copyleft semelhante) agora é padrão para bancos de dados para impedir que provedores de nuvem monetizem trabalho com licença permissiva sem contribuir de volta.
- Vários sugerem licenciamento duplo (AGPL + comercial) e a criação de acordos adequados de contribuição; alguns temem que apenas a empresa principal se beneficie financeiramente do trabalho da comunidade.
- Há confusão e divergência sobre o que a AGPL exige; alguns afirmam que clientes normais de banco de dados estão seguros, enquanto outros enfatizam que a AGPL é juridicamente pouco testada e arriscada.
- Alguns observam que, se o ganho de desempenho for real, grandes اللاعبين poderiam reimplementar o Postgres por conta própria sob termos permissivos, especialmente dado o custo aparentemente baixo com ajuda de IA.
Porta Gerada por IA e Preocupações com Copyright
- O histórico de commits do repositório mostra milhares de commits coautorizados por IA ao longo de um mês; alguns chamam isso de “AI slop” ou “vibecoded” e questionam a profundidade da revisão humana.
- O processo descrito: C→Rust via c2rust, depois uma refatoração pesada com LLM mais testes. Críticos argumentam que isso é claramente um trabalho derivado e moralmente (se não legalmente) questionável relicenciar para AGPL.
- Há debate sobre se código gerado por LLM é sequer protegível por copyright; alguns sugerem que a licença pode ser irrelevante, mas isso é apontado como incerto.
Reivindicações de Desempenho e Benchmarks
- A alegação de marketing é de ~300x mais rápido que o Postgres para analytics; vários comentaristas estão céticos.
- Críticos destacam que uma demonstração desativou o paralelismo do Postgres, fazendo a comparação parecer pior; os mantenedores dizem que o número de 300x vem de resultados do ClickBench com paralelismo ativado.
- Um especialista externo teria revisado execuções do ClickBench e confirmado ganhos grandes de velocidade; outros alertam que os testes podem refletir cargas analíticas específicas em memória, não uso OLTP geral.
- A discussão observa que muitas cargas de trabalho são limitadas por memória e cache; execução colunar e vetorizada pode, de fato, gerar ganhos muito grandes para certas consultas analíticas.
Correção, Confiabilidade e Longevidade
- A equipe do projeto enfatiza a correção: verificação formal de ~1000 funções, fuzzing diferencial contra o Postgres e engajamentos externos para testes de falhas e verificação.
- Eles relatam ~100 bugs encontrados no pgrust e ~20 no Postgres, incluindo bugs sutis de ponto flutuante.
- Muitos ainda se preocupam que um sistema de banco de dados jovem, gerado por IA, não consiga igualar as décadas de testes de batalha do Postgres; preocupações com corrupção de dados e manutenção de longo prazo são frequentes.
Arquitetura, Recursos e Casos de Uso
- O pgrust adiciona armazenamento colunar como um método de acesso a tabelas, planejamento adaptativo, um novo escalonador de consultas com limitação de recursos e work stealing, e um “test mode” para acelerar a clonagem do banco.
- Ele pode ser incorporado (inclusive para Wasm) e pode oferecer suporte a bancos efêmeros por teste, réplicas analíticas somente leitura via WAL e implantações mais leves.
- Alguns o veem como um mecanismo analítico compatível com Postgres e promissor; outros duvidam que ele substitua o Postgres, mas acreditam que pode coexistir para cargas de trabalho específicas.