O Postgres que você conhece, só que em Rust

Se alguém te dissesse que um desenvolvedor solo reescreveu o PostgreSQL inteiro em Rust usando IA e que o resultado passa 100% dos testes de regressão, você provavelmente responderia “tá bom, e eu sou o Linus Torvalds”. Eu também duvidaria. Mas o pgrust existe, tem 7 mil commits no GitHub, roda no navegador via WebAssembly e, nos benchmarks internos, já mostra números que fariam qualquer DBA levantar da cadeira.

Michael Malis e Jason Seibel pegaram o PostgreSQL 18.3, a versão mais recente, e reconstruíram do zero em Rust. Não é um fork. Não é um wrapper. É uma reimplementação completa que lê diretórios de dados do Postgres original e executa as mesmas queries com o mesmo comportamento. O projeto passou por todas as 46.066 queries da suíte de regressão do PostgreSQL sem falhar uma sequer.

Eu acompanho rewrites há anos (a tradução do compilador Rust para C é outro exemplo recente). A maioria morre antes de atingir 20% de compatibilidade. O pgrust chegou a 100% em semanas, não meses. E a explicação para essa velocidade tem um nome: Codex 5.4.

250 mil linhas de Rust em duas semanas

Vamos aos números que importam. Michael Malis usou o Codex 5.4 (modo fast) como ferramenta principal de desenvolvimento. Nos primeiros sete dias, ele construiu a fundação: parser SQL, camada de storage, controle de concorrência e executor de queries. No primeiro dia, em pouco mais de três horas, já tinha execução básica de queries funcionando.

A partir do oitavo dia, a abordagem mudou. Features pequenas que precisavam de integração profunda com o codebase se mostraram mais difíceis para a IA do que features grandes e autocontidas. Parece contraintuitivo, certo? Mas faz sentido: uma feature isolada tem fronteiras claras, enquanto uma correção pontual exige entender o contexto de dezenas de arquivos.

A solução foi escalar para múltiplos agentes. No pico, 17 agentes de código diferentes trabalhavam em paralelo no mesmo repositório. Cada agente recebia uma fatia de testes para passar, fazia commits frequentes e pequenos, e o merge acontecia de forma incremental. A estratégia de “commit cedo, commit sempre” eliminou os gargalos de integração que apareceram quando agentes tentavam entregar features completas de uma vez.

O que não funcionou: merges grandes. Quando dois agentes modificavam o parser ou o executor ao mesmo tempo, as sessões de merge levavam até duas horas. A lição foi dividir o trabalho por subsistema, não por feature.

Thread por conexão: a aposta arquitetural

O PostgreSQL tradicional usa um modelo de processo por conexão. Cada cliente que se conecta recebe um processo dedicado no sistema operacional. Isso oferece isolamento excelente (se um processo crashar, os outros continuam), mas tem um custo: comunicação entre processos é cara, e compartilhar memória exige mecanismos como shared buffers com semáforos.

O pgrust fez diferente: thread por conexão. Em vez de processos separados, cada conexão roda em uma thread dentro do mesmo processo. A vantagem imediata é que threads compartilham memória naturalmente. Não precisa copiar tuplas entre processos para execução paralela de queries. O shared buffer vira simplesmente memória compartilhada entre threads, sem overhead de IPC.

// Modelo simplificado do pgrust
// Cada conexão é uma thread, não um processo
fn handle_connection(stream: TcpStream, shared_state: Arc<SharedState>) {
    let mut conn = Connection::new(stream, shared_state);
    loop {
        match conn.read_query() {
            Ok(query) => conn.execute(query),
            Err(_) => break,
        }
    }
}

Na prática, isso significa que queries analíticas que precisam escanear grandes volumes de dados podem distribuir o trabalho entre threads sem o custo de serialização e deserialização que o Postgres original paga ao usar processos. O resultado aparece nos benchmarks: 300x mais rápido em workloads analíticos.

Mas tem um porém. O modelo de processos do PostgreSQL não existe só por capricho. Ele protege contra extensões mal escritas. Se uma extensão em C corrompe memória num processo, o kernel isola o dano. Com threads, uma extensão bugada pode derrubar o servidor inteiro. A comunidade no Hacker News levantou esse ponto, e as sugestões incluem sandboxing via WebAssembly para extensões ou isolamento em réplicas de leitura.

Benchmarks: 50% mais rápido em transações, 300x em analytics

Os números de performance do pgrust são preliminares (o projeto ainda não passou por otimização dedicada), mas já chamam atenção:

O ganho transacional de 50% vem principalmente da eliminação do overhead de criação de processos e do custo de IPC. Cada fork() no PostgreSQL tradicional copia tabelas de páginas, configura file descriptors e aloca memória. Com threads, a criação de uma nova conexão é ordens de magnitude mais barata.

O ganho analítico de 300x é o mais impressionante e vem do compartilhamento direto de memória. Quando o pgrust precisa fazer um sequential scan numa tabela grande, ele pode dividir o trabalho entre threads que acessam os mesmos buffers sem cópia. No Postgres original, queries paralelas precisam de background workers que são processos separados, cada um com seu próprio mapeamento de memória compartilhada.

E o ClickBench? Ser apenas 2x mais lento que o ClickHouse num benchmark analítico é surpreendentemente bom para um banco relacional de propósito geral. O ClickHouse é uma engine colunar otimizada especificamente para analytics, com anos de otimização manual em hot paths. O pgrust chegar perto disso sem otimização dedicada sugere que a arquitetura baseada em threads tem espaço para melhorar ainda mais.

Compatibilidade: disco, queries e o que falta

Um dos aspectos mais ambiciosos do pgrust é a compatibilidade com disco. Você pode literalmente pegar um data directory do PostgreSQL 18.3, apontar o pgrust para ele e ele vai inicializar e servir queries. Isso significa que migrar do Postgres para o pgrust (quando estiver pronto) seria trocar o binário, não fazer dump e restore.

A compatibilidade funcional também é notável. Os 46.066 testes de regressão cobrem:

• Tipos de dados (inteiros, floats, text, JSON, arrays, composites)
• Joins (inner, outer, cross, lateral)
• Subqueries e CTEs
• Window functions
• Transações e savepoints
• Triggers e rules
• PL/pgSQL (linguagem procedural)
• Funções de agregação
• Full text search
• Operações com índices (B-tree, Hash, GiST, GIN)

Além da suíte de regressão, o pgrust também passa os testes de isolamento, que verificam comportamento correto em cenários de concorrência e locking.

O que ainda não funciona:

• Extensões nativas: extensões compiladas em C (como PostGIS, pg_stat_statements, TimescaleDB) não são compatíveis. O pgrust usa Rust, então as extensões precisariam ser portadas ou rodadas via algum mecanismo de compatibilidade.
• Linguagens procedurais externas: PL/Python, PL/Perl e PL/Tcl não estão disponíveis. PL/pgSQL funciona porque foi reimplementado em Rust.
• Replicação: streaming replication e logical replication ainda não foram implementados.
• Produção: os próprios criadores enfatizam que o projeto não está pronto para produção. Bugs existem, edge cases não cobertos pelos testes de regressão podem causar comportamento inesperado.

Como IA reescreveu um banco de dados de 30 anos

A parte mais provocativa do pgrust não é o Rust. É como a IA foi usada. Michael Malis documentou o processo em detalhes no blog dele, e vale a pena entender a metodologia porque ela desafia várias suposições sobre desenvolvimento assistido por IA.

Passo 1: entender antes de reescrever. O Codex não recebeu o código C do Postgres e a instrução “traduza para Rust”. Em vez disso, Malis apontava o agente para um subsistema do Postgres e pedia que explicasse como funcionava. Só depois de entender a arquitetura, ele colaborava com o agente para construir uma versão em Rust.

Passo 2: testes como oráculo. A suíte de regressão do PostgreSQL serviu como especificação viva. Em vez de escrever specs ou documentação, a meta era simples: “faça esse teste passar”. Cada teste que passava era uma feature confirmada.

Passo 3: features grandes antes de features pequenas. Isso é contraintuitivo. Normalmente você começa pelo fácil e escala. Mas Malis descobriu que a IA era melhor em construir subsistemas grandes e autocontidos (como o parser JSON inteiro) do que em fazer ajustes pontuais que exigiam entender o contexto de dezenas de arquivos. Features grandes têm fronteiras claras; patches pequenos exigem conhecimento profundo do codebase.

Passo 4: orquestração multi-agente. Com 17 agentes trabalhando em paralelo, a coordenação se tornou o gargalo. A solução foi tratar cada agente como um contributor open-source: ele recebe um conjunto de testes para passar, faz commits frequentes, e o “maintainer” (Malis) resolve conflitos.

O resultado desafia a narrativa de que IA só serve para boilerplate. O pgrust não é um CRUD. É um banco de dados relacional completo com parser, planner, executor, sistema de transações, WAL, catálogo de sistema e dezenas de tipos de dados. E foi construído em duas semanas por uma pessoa com assistência de IA.

O elefante na sala: vale a pena reescrever o Postgres?

Eu sei o que você está pensando. O PostgreSQL tem 30 anos de desenvolvimento (e até a Microsoft está apostando nele), milhares de contributors, e é provavelmente o banco de dados mais confiável do planeta. Por que alguém reescreveria isso?

A resposta do projeto é pragmática: não para substituir, mas para experimentar. O código C do PostgreSQL é difícil de modificar. Adicionar multithreading nativo, por exemplo, exigiria mudanças tão profundas que a comunidade do Postgres discute isso há mais de uma década sem consenso. O pgrust, por começar do zero em Rust, pode explorar essas mudanças sem o peso de 30 anos de backward compatibility.

O roadmap deixa isso claro:

• Multithreaded internals: já implementado parcialmente com o modelo thread-per-connection
• Connection pooling nativo: sem precisar de PgBouncer ou Pgpool
• Experimentos de storage: designs sem vacuum (o autovacuum é a dor de cabeça #1 de DBAs em Postgres)
• Fast forking e branching: criar branches de um banco como se fosse um repositório Git

Esse último ponto é particularmente interessante. Imagine fazer pgrust branch dev e ter uma cópia copy-on-write do seu banco para desenvolvimento, sem gastar disco. Algo parecido com o que o Neon faz, mas integrado diretamente no engine.

O que a comunidade pensa

O post no Hacker News gerou mais de 600 comentários, o que por si só já indica que o assunto mexeu com os devs. As reações se dividem em três campos:

Os céticos apontam que 100% dos testes de regressão não significa 100% de compatibilidade. A suíte de regressão do Postgres não cobre todos os edge cases, especialmente em cenários de concorrência pesada, recovery após crash e comportamento de extensões. Um comentário resumiu: “passar nos testes é a parte fácil; os bugs que os testes não cobrem é que vão te pegar em produção”.

Os pragmáticos reconhecem o valor como prova de conceito. Mesmo que o pgrust nunca substitua o Postgres em produção, ele demonstra que: (a) rewrites assistidos por IA são viáveis para projetos complexos, (b) o modelo thread-per-connection merece investigação séria, e (c) Rust pode ser uma linguagem viável para bancos de dados de produção.

Os preocupados levantam a questão do Cargo.lock com 1.467 dependências. No Postgres original, as dependências externas são mínimas. Cada crate no Cargo.lock é uma superfície de ataque potencial e um ponto de falha. Se um crate quebrar compatibilidade ou for comprometido num supply chain attack, o pgrust inteiro é afetado.

Uma crítica particularmente afiada veio sobre o processo de code review. Com 7 mil commits gerados majoritariamente por IA, quem revisou esse código? A resposta honesta é: os testes. O pgrust adota uma filosofia onde os testes são a especificação, e se os testes passam, o código está correto. Funciona para comportamento funcional, mas não captura problemas de segurança, memory leaks sutis ou race conditions que os testes não exercitam.

Você pode testar agora

O pgrust tem uma demo interativa em pgrust.com que roda inteiramente no navegador via WebAssembly. Você pode abrir o site e executar queries SQL contra uma instância do pgrust sem instalar nada. É impressionante ver um banco de dados relacional completo rodando dentro de uma aba do Chrome.

Para quem quer ir mais fundo, o código está no GitHub sob licença AGPL-3.0. A escolha da AGPL é intencional: garante que qualquer serviço que use o pgrust precisa abrir o código modificado. É a mesma estratégia que empresas como a MongoDB usaram para proteger o projeto de cloud providers que poderiam oferecer “pgrust-as-a-service” sem contribuir de volta.

# Clonar e compilar o pgrust
git clone https://github.com/malisper/pgrust.git
cd pgrust
cargo build --release

# Inicializar com um data directory existente do Postgres 18.3
./target/release/pgrust --data-dir /var/lib/postgresql/18/main

# Ou criar um novo
./target/release/pgrust initdb --data-dir ./pgdata
./target/release/pgrust --data-dir ./pgdata

O que vem pela frente

O pgrust está longe de ameaçar o PostgreSQL em produção. Mas o que ele representa é mais importante do que o que ele é hoje. É a prova de que um único desenvolvedor com ferramentas de IA pode reconstruir um dos softwares mais complexos já criados em questão de semanas, não anos.

Para quem trabalha com Postgres no dia a dia, o projeto vale a pena ser acompanhado por três motivos: as otimizações de performance que ele está explorando (especialmente o modelo de threads) podem eventualmente influenciar o Postgres original; a abordagem de storage sem vacuum pode resolver a maior dor de cabeça operacional do PostgreSQL; e a metodologia de desenvolvimento com IA multi-agente é um estudo de caso que vai ser referência por muito tempo.

Se você é DBA ou backend dev que vive no Postgres, rode a demo no browser, leia os posts do blog e acompanhe o repositório. E se você acha que reescrever o Postgres é loucura, lembre que disseram a mesma coisa quando o Linus resolveu reescrever o Minix.