Reescrevendo o Postgres em Rust, agora com 100% de aprovação nos testes de regressão do Postgres

 (github.com/malisper)
1 pontos por GN⁺ 5 시간 전 | 1 comentários | Compartilhar no WhatsApp
  • pgrust é um projeto de reescrita em Rust com o objetivo de ser compatível com o Postgres 18.3 e corresponde à saída esperada do Postgres em mais de 46.000 consultas de regressão
  • Tem compatibilidade de disco para inicializar a partir de um diretório de dados do Postgres 18.3 existente e usa os testes reais do Postgres como referência de comportamento
  • No momento, não está pronto para produção e ainda não recebeu otimizações de desempenho; extensões existentes do Postgres e extensões de linguagens procedurais como PL/Python, PL/Perl e PL/Tcl geralmente não são compatíveis
  • É possível testar pelo demo em WebAssembly e pela imagem Docker malisper/pgrust:v0.1; latest aponta para a mesma release por enquanto, mas a imagem fixa de execução é v0.1
  • O roadmap inclui estrutura interna multithread do Postgres, pool de conexões embutido, melhorias para workloads centradas em JSON, experimentos de armazenamento sem vacuum e guardrails em tempo de execução para SQL gerado por IA

Objetivos e compatibilidade do pgrust

  • pgrust é um projeto para reescrever o Postgres em Rust
  • O alvo é o Postgres 18.3 e ele corresponde à saída esperada do Postgres em mais de 46.000 consultas de regressão
  • Fornece compatibilidade de disco para inicializar a partir de um diretório de dados existente do Postgres 18.3
  • O objetivo do projeto é tornar mais fácil modificar o Postgres internamente
    • Mantendo o comportamento no formato do Postgres
    • Usando os testes reais do Postgres como referência
    • Explorando mudanças mais profundas no servidor com Rust e programação assistida por IA

Estado atual e limitações

  • O pgrust ainda não está pronto para produção
  • Ainda não houve otimização de desempenho
  • Extensões existentes do Postgres e extensões de linguagens procedurais geralmente ainda não são compatíveis
    • PL/Python
    • PL/Perl
    • PL/Tcl
  • Alguns módulos contrib empacotados já foram portados, e mais compatibilidade pode surgir com o tempo

Como executar

  • O demo em WebAssembly pode ser testado em https://pgrust.com
  • Para executar com Docker, use a imagem malisper/pgrust:v0.1
    • Use o cliente psql dentro da imagem
    • malisper/pgrust:latest aponta para a mesma release no momento
    • A imagem de release fixa é v0.1
docker run -d --name pgrust -e POSTGRES_PASSWORD=secret malisper/pgrust:v0.1 && until docker exec -e PGPASSWORD=secret pgrust psql -h 127.0.0.1 -U postgres -c '\q' >/dev/null 2>&1; do sleep 1; done && docker exec -it -e PGPASSWORD=secret pgrust psql -h 127.0.0.1 -U postgres; docker rm -f pgrust

Compilação a partir do código-fonte e execução

  • No macOS, são necessários icu4c, openssl@3 e libpq
brew install icu4c openssl@3 libpq

export LIBRARY_PATH="$(brew --prefix openssl@3)/lib:${LIBRARY_PATH:-}"
export PKG_CONFIG_PATH="$(brew --prefix openssl@3)/lib/pkgconfig:$(brew --prefix icu4c)/lib/pkgconfig:${PKG_CONFIG_PATH:-}"
export PATH="$(brew --prefix libpq)/bin:$PATH"
  • No Debian/Ubuntu, instale ferramentas de build, ICU, OpenSSL, LDAP, PAM e o cliente Postgres 18
sudo apt-get update
sudo apt-get install -y build-essential pkg-config libicu-dev libssl-dev libldap2-dev libpam0g-dev postgresql-client-18
  • A compilação é feita com cargo build, apontando para o diretório compartilhado vendorizado do Postgres 18.3
PGRUST_PGSHAREDIR="$PWD/vendor/postgres-18.3/share" \
cargo build --release --locked --bin postgres
  • O diretório de dados é criado com o --initdb do pgrust
target/release/postgres --initdb \
  -D /tmp/pgrust-data \
  -L "$PWD/vendor/postgres-18.3/share" \
  --no-locale \
  --encoding UTF8 \
  -U postgres
  • Na execução, use junto as configurações relacionadas à pilha e as configurações de I/O síncrona
ulimit -s 65520

RUST_MIN_STACK=33554432 target/release/postgres \
  -D /tmp/pgrust-data \
  -F \
  -c listen_addresses= \
  -k /tmp \
  -p 5432 \
  -c io_method=sync \
  -c max_stack_depth=60000

Testes de regressão e resultados de validação

  • Os testes de regressão do Postgres são executados com scripts/run-regression
PGRUST_BIN="$PWD/target/release/postgres" \
scripts/run-regression
  • O runner de testes usa o próprio --initdb do pgrust e os arquivos de teste do Postgres 18.3 incluídos no repositório
  • É necessário ter o cliente psql do Postgres 18 no PATH
    • Se estiver em outro local, defina PGRUST_PSQL=/path/to/psql
  • O resultado validado da release é que o pgrust correspondeu à saída esperada do Postgres em mais de 46.000 consultas de regressão

Roadmap e histórico do projeto

  • O roadmap inclui os seguintes itens

    • Estrutura interna multithread do Postgres

      • Pool de conexões embutido
      • Melhor suporte para workloads centradas em JSON
      • Workflows rápidos de fork e branching
      • Experimentos de armazenamento, incluindo design sem vacuum
      • Guardrails em tempo de execução para consultas incorretas e SQL gerado por IA
      • Redução de mudanças repentinas para planos de execução ruins
      • O repositório atual contém uma implementação mais nova do pgrust que alcançou o marco dos testes de regressão
      • A implementação pública anterior está arquivada em archive/pre-fabled-2026-06-23
      • Links de contexto relacionados
      • Original pgrust launch
      • 67% regression update
      • Four Horsemen roadmap
      • A licença é AGPL-3.0

Leituras relacionadas

1 comentários

 
GN⁺ 5 시간 전
Comentários no Hacker News

  • Sou o autor original. Não esperava que isso fosse aparecer aqui. Resumindo, venho fazendo experimentos para criar um Postgres melhor com LLM, e acho que, em 30 anos de Postgres, também aprendemos bastante sobre bancos de dados
    Muitas das técnicas úteis para uma reescrita também são úteis para um redesenho. A nova versão do pgrust, que ainda não foi publicada, atualmente passa em 100% dos testes de regressão do Postgres, implementa um modelo de thread por conexão em vez do modelo de processo por conexão do Postgres, é 50% mais rápida que o Postgres em cargas transacionais e cerca de 300 vezes mais rápida em cargas analíticas
    No momento é 2 vezes mais lenta que o ClickHouse no clickbench, mas acho que pode ficar mais rápida que o ClickHouse. Se tiverem perguntas, responderei

    • Thread por conexão quase sempre é a escolha certa do ponto de vista de desempenho, mas o fato de o Postgres ter escolhido processo por conexão permite carregar extensões suspeitas à vontade. No pior caso, morre só aquele processo, e não o banco inteiro. Seria bom ter um meio-termo em que um erro de segmentação numa extensão mate só algumas conexões, e não tudo
    • Essa melhora de 50% em OLTP parece meio suspeita. Não quero criticar sem base, e eu mesmo faço alegações de benchmark com frequência, mas mesmo sabendo que você usou benchmark padrão, meu faro está apitando
      Pode ser que em algum lugar tenha quebrado o MVCC e feito um compromisso que não serve para produção. Vi que passa nos testes de regressão. O fsync está ligado? Pelo que sei, testes de regressão não capturam bem padrões ruins de E/S. Ainda assim, parece um projeto interessante
    • Tenho curiosidade sobre sua bagagem real e sua experiência com Postgres e com bancos de dados em geral. No fim, quero saber se você sabe exatamente o que está fazendo, ou se existe alguma mina terrestre gigantesca escondida que você ainda não conhece
    • Isso parece mais um experimento do que um lançamento de produto, mas alguém te empurrou para debaixo do ônibus do spotlight do HN. Fico curioso se isso é um experimento para ver até onde dá para ir com coding via LLM, ou se é um experimento de construir primeiro e depois ver quanto do código escrito pelo LLM pode ser aproveitado
    • Ser cerca de 300 vezes mais rápido que o Postgres em cargas analíticas e 2 vezes mais lento que o ClickHouse significa que os dados são armazenados em formato colunar? Ou você usa tanto formato em linha quanto colunar?
      Estou fazendo um trabalho parecido, mas diferente, com o δx. É uma extensão do Postgres que armazena dados comprimidos em formato colunar dentro de tabelas normais do Postgres, então replicação, recuperação de falhas, pg_dump etc. continuam funcionando: https://github.com/xataio/deltax
      Atualmente, em nó único, fica de 30% a 40% atrás do ClickHouse. Acabaram de aceitar o PR para adicionar ao clickbench, então dá para ver a comparação aqui: https://benchmark.clickhouse.com/#system=+liH|_etx|gQ|saB&ty...

  • Não entendo muito bem esse tipo de reescrita. Normalmente é tocada por uma pessoa só, o que tende a virar um ponto único de falha, e é criada em pouquíssimo tempo, então fica difícil dizer que houve aprendizado da disciplina de construir um projeto de forma consistente
    Também parece pouco provável que seja mantida no médio e longo prazo. Quem quiser contribuir também vai ter de pagar custo de tokens. Porque está ficando cada vez mais difícil manter esse tipo de projeto sem AI. Será que alguém gostaria de colocar isso em produção? Não parece fazer muito sentido

    • Não é só uma reescrita, também há melhorias. Fiz algo parecido por diversão, porque queria ver se era possível melhorar projetos antigos e, em especial, partes que o pessoal do PostgreSQL dizia que “não dava para fazer diferente”. E dá, sim, para fazer diferente
      Eu não colocaria em produção, mas aprendi muito sobre o funcionamento interno de bancos de dados. Mesmo na era do LLM, para exercitar a cabeça, também implemento funcionalidades de banco de dados no nosso banco de produção sem LLM. No momento estou apanhando com Flexible Paxos, e provavelmente vou continuar usando o velho, estável e simples Raft, mas ainda assim é interessante
    • Vejo isso como uma prova de conceito interessante. Não é só reescrever o PostgreSQL em Rust, mas também testar a viabilidade das dependências escolhidas, da mudança no modelo de threads e de outras mudanças de arquitetura
      LLM é muito bom para produzir protótipos extremamente rápido, e um protótipo funcional pode eliminar muita especulação. Eu provavelmente não usaria uma reescrita de um projeto tão grande sem que o time original ou um grupo considerável desse suporte, nem sem uma explicação confiável de que igualou ou superou a qualidade e a manutenibilidade do código original
      Em geral, acho difícil defender legal ou moralmente a lavagem de licença com LLM. Mas, neste caso, é diferente porque ele escolheu uma licença mais restritiva. Não sou advogado, mas entendo que seria legalmente possível baixar o PostgreSQL, fazer s/MIT/AGPL/ e redistribuir. A versão original sob licença MIT continua existindo, então, até aparecer alguma funcionalidade nova realmente convincente, não há muito motivo para preferir essa versão
    • Não é exatamente a mesma coisa, mas refazer um modelo 3D com base num conjunto de plantas existente é muito mais rápido e fácil do que fazer do zero. Isso porque muitas decisões já foram tomadas
    • Num projeto do porte do Postgres, manter sem AI é, na prática, quase impossível. Se bem me lembro, o Postgres tem mais de 1 milhão de linhas

  • A melhor forma de testar isso parece ser colocar um proxy como o PgBouncer na frente de um banco de produção movimentado e espelhar as queries ao mesmo tempo para o Postgres atual e para a versão em Rust
    Aí daria para comparar saída e desempenho sob carga real. Depois de deixar rodando por um tempo, também daria para comparar, tabela por tabela, com uma instância normal do Postgres

  • Como revisar um código assim? Normalmente eu dou uma olhada no histórico de commits para ver o que as pessoas fizeram e como trabalharam, mas se um LLM gera 7.101 commits em menos de um mês isso fica impossível
    Só um dia já é coisa demais para ver [1]. E, de qualquer forma, o conteúdo dos commits pode não dizer muita coisa. Também queria saber se existe um jeito fácil de ir ao primeiro commit de um repositório no GitHub. Explorar o histórico de commits parece bem incômodo
    [1] - https://github.com/malisper/pgrust/commits/main/?since=2026-...

    • Estou trabalhando com o malisper no pgrust. Em projetos assim, acho que o foco vai mudar de revisar cada commit para revisar o processo de testes e fuzzing
      Isso precisa ir bem além dos testes de regressão, isolamento e falha do Postgres. Texto relacionado do danluu: https://danluu.com/ai-coding/
    • O github cli tem um comando para consultar commits com flag de ordenação ascendente/descendente: https://cli.github.com/manual/gh_search_commits
      A documentação da sintaxe tipo before x date está aqui: https://docs.github.com/en/search-github/searching-on-github...
      Também existe a página de busca avançada, mas ela não suporta commits com filtro por data: https://github.com/search/advanced
      Também dá para fazer busca binária nas datas no widget de busca, e o primeiro dia com commits é este: https://github.com/malisper/pgrust/commits/main/?since=2026-...
      Primeiro commit: https://github.com/malisper/pgrust/commit/22113dc36b02973060...
    • Em termos gerais, se não houver histórico de prompts e não for possível reexecutar diretamente a “compilação” do LLM, fica ambíguo se isso é código aberto. Dá até a sensação de estar mais perto de um projeto de “código-fonte disponível”, em que dá para ler o código, mas não ter acesso ao sistema de build
      Por outro lado, tirando as mensagens de commit, nunca tivemos acesso ao processo interno de pensamento de desenvolvedores humanos, então também não é exatamente a mesma coisa dizer que prompts secretos equivalem a código-fonte fechado
    • Para ir facilmente ao primeiro commit no GitHub, dá para usar a sintaxe github.com/user/repo/commits/?after=last_commit_hash+number_of_commits-2. É tipo fazer -1, -1 por causa do commit mais recente e do último commit
      Exemplo: https://github.com/malisper/pgrust/commits/?after=3646a73515...
    • Não reviso. Só resta acreditar que passar nos testes de regressão significa compatibilidade total com o original

  • É impressionante, mas é uma mudança de licença: da licença do PostgreSQL [0] para a AGPL [1]
    Eu gosto da AGPL e acho que ela é a melhor entre as licenças de software livre/open source de verdade, mas fico preocupado com a compatibilidade. Se foi reescrito a partir do código-fonte original, a licença original não deveria valer? Acho que sim. Já houve esse movimento de reescrever software open source sob licenças mais restritivas, como o coreutils em Rust. O fato de terem escolhido AGPL parece muito mais ético, mas não teria sido mais seguro simplesmente não mudar?
    [0] https://www.postgresql.org/about/licence/
    [1] https://github.com/malisper/pgrust?tab=AGPL-3.0-1-ov-file

    • Acho que você entendeu ao contrário a direção da restritividade. O uutils coreutils, com licença MIT, é menos restritivo que o GNU coreutils, com GPL, e a AGPL é mais restritiva que a licença do PostgreSQL
      Distribuir uma reimplementação sob uma licença mais restritiva não viola a licença do PostgreSQL. Licenças da família MIT são menos restritivas que GPL ou AGPL justamente porque permitem esse tipo de relicenciamento mais restritivo
    • Se você não gostou da licença, é só mandar um LLM “portar” por alguns dias e então aplicar a licença que quiser. Pelo visto é assim que se faz hoje em dia
    • A licença do PostgreSQL é uma variação da licença BSD, então é compatível com (A)GPL
      Dá para pensar assim: você cria um projeto (A)GPL vazio e importa o codebase BSD upstream. Os arquivos originais do upstream continuam sob a licença permissiva original, mas o projeto como um todo passa a ser regido pela (A)GPL, incluindo a exigência de atribuição da licença upstream. A GPL permite esse tipo de exigência. Depois você adiciona seu próprio código em AGPL e pode distribuir a obra combinada sob AGPL
      Se alguém pegar apenas as partes do código que você escreveu, basta seguir a AGPL. Mas, se incluir também o código upstream, essa pessoa continua tendo de cumprir as exigências de atribuição da licença upstream
    • A licença do Postgres já é totalmente compatível com a AGPL. BSD/MIT são mais permissivas

  • Há 2664 ocorrências de unsafe { e 1835 de unsafe fn. Isso está longe de ser totalmente seguro. Não parece uma reescrita feita por alguém que entendeu o que realmente está acontecendo e como redesenhar a arquitetura para aproveitar as vantagens do Rust
    Em vez disso, parece uma conversão gerada por IA com uso extensivo de ponteiros brutos

    • A maior parte do unsafe está confinada ao parser gerado ao rodar c2rust no parser do Postgres. Como o próprio parser do Postgres também é gerado por yacc/bison, a decisão foi portar mecanicamente em vez de reescrever em Rust idiomático
      Se houver algum unsafe que você considere especialmente grave, seria bom saber
    • Em todos os projetos de LLM que escrevo em Rust, configuro unsafe=deny. Não sei por que ninguém prevê esse tipo de reação
    • Dá para simplesmente copiar este comentário de revisão no prompt. Em algumas horas provavelmente vai virar “corrigido!”

  • Acho que precisamos distinguir com força entre reescrita e reescrita por IA

    • Por exemplo, a reescrita do TypeScript em Go foi feita majoritariamente por humanos e levou um ano até ser publicada. É assim que se fazem reescritas de software em que as pessoas podem confiar
    • Não parece ser tão simples assim. Quase 100% dos projetos novos e ambiciosos provavelmente vão usar IA em algum grau. Conheço alguns poucos projetos, como o Zig, com uma política rígida de não usar IA, mas são minoria absoluta
      Então, qual seria o nível de uso de IA a partir do qual isso vira uma “reescrita por IA”?
    • Reescrita parece justamente uma área em que LLMs se encaixam melhor do que humanos. Em grande parte é trabalho repetitivo e mecânico, e LLMs funcionam bem para tarefas de tradução. Se lembro bem, a arquitetura transformer originalmente também foi inventada para tradução
    • Uma reescrita humana sem manutenção não passa de um projeto de hobby. Já uma reescrita por IA, nem sei para que serve gastar tokens nisso
    • A esta altura, isso simplesmente virou uma etapa de build

  • Vejo muitos desses projetos de reescrita afirmando que funcionam por depender de testes. Mas o que torna confiável um software como Postgres ou SQLite não são os testes em si, e sim algo mais próximo das cicatrizes acumuladas em produção
    Confiabilidade se acumula ao longo de anos rodando em ambientes reais

    • A maior parte de uma suíte de testes enorme é justamente cicatriz de produção. Sempre que aparece um bug ou uma regressão, escreve-se um teste para verificar o comportamento correto
      SQLite é um bom exemplo. A enorme suíte de testes privada do SQLite é frequentemente citada como algo que dificulta forks. A Turso conseguiu fazer isso, mas para garantir um nível equivalente de diligência é preciso uma empresa. E, claro, também são necessários anos de operação
    • Não é um julgamento sobre esta reescrita específica, mas testes são a especificação de que o software funciona corretamente. Se algum comportamento não está coberto por testes automatizados, não dá para afirmar que uma mudança específica não o quebrou
      Dizer que algo funciona usando a suíte de testes original sem modificações é totalmente razoável. Quanto maior o projeto, mais isso vale. As cicatrizes de produção precisam ser documentadas e protegidas na suíte de testes; caso contrário, essa lição se perde
      O SQLite é famoso por sua suíte de testes gigantesca e por fuzzing extensivo. Há 590 vezes mais código e scripts de teste do que código comum. Fonte: https://sqlite.org/testing.html
    • Então o ideal seria tornar mais fácil devolver essa confiabilidade para o upstream
      A coisa mais útil que dá para fazer agora com essas versões convertidas por LLM é: se a versão convertida passa em todos os testes originais, rodar por cima dela a suíte de testes da minha aplicação para encontrar lacunas na cobertura de testes do original
      Se a versão convertida trava ou apresenta mau funcionamento observável, isso significa que faltava algum teste de regressão no projeto real. Se esses projetos de conversão puderem ser executados com segurança e facilidade como mais uma linha da matriz normal de testes de integração, o upstream poderá evitar muito melhor quebrar algo sem querer em atualizações futuras
    • Concordo. Também concordo com o comentário ao lado de que, sempre que aparece um bug ou uma regressão, escreve-se um teste para verificar o comportamento correto
      Mas o que não fica claro nessas reescritas é: o que fazer com bugs novos introduzidos pela própria reescrita? No fim, ela também não precisa enfrentar cenários do mundo real por conta própria?
    • Há outras formas de validar uma reescrita. Basta executar pgrust e postgres lado a lado e comparar as saídas
      Se você conhece casos de borda, pode rodá-los também; se não conhece, pode usar um fuzzer ou ferramentas automatizadas para encontrar entradas interessantes. Quando encontrar divergências, esse par de entrada/saída vira um caso de teste. Não sei se já existe uma ferramenta assim, mas, se existir, é só entregar para o Claude e colocá-la no loop de desenvolvimento

  • A demo em WebAssembly rodando no navegador é realmente muito caprichada: https://pgrust.com

  • Não sei por que tanto pessimismo. Acho esse tipo de projeto interessante para fins de aprendizado e para explorar novas abordagens. Qual é o problema nisso?

    • Talvez o motivo seja este. Ele pega carona numa marca já estabelecida, Postgres + Rust, sem utilidade prática nem progresso real, e com pouca credibilidade
      Especialmente quando um nome com um sinal forte como Postgres aparece no título e isso é usado como destaque, se for claramente impraticável por razões como utilidade de curto e longo prazo, confiança social e efeitos de rede, parece fácil gerar rejeição
    • É desconfortável ver décadas de trabalho sendo copiadas com tanta facilidade
    • Fico me perguntando exatamente o que se aprende ao mandar uma LLM reescrever isso
    • Parece que as pessoas se sentem ameaçadas ao ver uma LLM fazer bem um trabalho que elas consideravam exigir sua própria habilidade e talento
      Dá para entender, mas é um sentimento negativo que não é produtivo nem muito racional. Esta thread está cheia de posts tentando dizer que isso não pode ser bom, não deveria ser bom e obviamente vai terminar em desastre. Mas o fato de essa coisa ter passado por dezenas de milhares de testes sofisticados acumulados ao longo de décadas sugere o contrário. É difícil rebater
      Claro, ainda é bem provável que surjam novos problemas, mas continua sendo uma conquista impressionante
    • Estou preocupado com a qualidade. Mesmo passando os olhos no código, ele parece meio idiota. A menos que eu simplesmente não esteja percebendo o lado genial do código
      https://github.com/malisper/pgrust/blob/3646a73515a5e4ac7d0b...
      https://github.com/malisper/pgrust/blob/3646a73515a5e4ac7d0b...