Escrevi um parser SQL 70x mais rápido quase sem olhar o código
Aprofundamento CEVIU
Aprofundamento
O PostHog conseguiu um salto brutal de desempenho ao substituir seu parser SQL baseado em ANTLR por uma implementação manual em Rust gerada com IA. O novo parser, escrito quase inteiramente por Claude Opus 4.7, adota uma arquitetura recursive-descent com núcleo Pratt para expressões, combinando previsibilidade e eficiência. Essa abordagem elimina as camadas de indireção típicas de geradores como ANTLR, que usam interpretação de grafos (ATN) em tempo de execução, e reduz drasticamente o custo por token processado.
O diferencial não foi só usar IA para gerar código, mas sim montar um fluxo robusto de validação: testes baseados em propriedades (PBT) com Hypothesis, gerador SQL derivado da gramática .g4 original, cobertura orientada por feedback e até agentes secundários pedidos para 'pensar muito sobre casos extremos'. Isso criou um loop fechado onde a IA corrigia divergências contra um oráculo (o parser C++), aprendendo continuamente sem perder consistência.
Por que isso importa
Parser é o primeiro ponto de contato com entrada não confiável. Um erro aqui compromete segurança, controle de acesso e otimizações downstream. Ao atingir equivalência funcional com o parser original, mesmo em queries absurdas como SELECT SELECT FROM FROM, o PostHog provou que soluções geradas por IA podem ser tão corretas quanto as manuais, mas com ganhos de performance antes inacessíveis.
Isso redefine o custo-benefício de se ter parsers customizados. Onde antes só valia a pena em cenários extremos, agora equipes pequenas podem construir parsers rápidos, seguros e mantidos por ferramentas automatizadas. O futuro dos compiladores e linguagens pode estar menos em gramáticas declarativas e mais em pares IA + PBT, treinando parsers especializados com velocidade e precisão.
Linha do tempo
Claude Opus 4.7 gera 16K linhas do novo parser SQL do PostHog em Rust, usando sessões longas paralelas e prompt engineering rigoroso
PostHog anuncia parser SQL 70x mais rápido em benchmarks locais e até 454x mais rápido em produção, com equivalência total ao parser anterior em C++ baseado em ANTLR
Perguntas frequentes
Como a IA conseguiu escrever um parser correto sem erros?
A IA não escreveu o parser perfeito de primeira. O segredo foi o oráculo: o parser C++ antigo serviu como referência. Sempre que os dois discordavam, o sistema gerava um teste de regressão. A equipe usou testes baseados em propriedades para forçar divergências, e a IA foi iterando até zerar as diferenças. O processo foi TDD em escala, guiado por dados.
Por que não usar ANTLR ou outro gerador de parser?
ANTLR é flexível, mas lento. Ele roda um interpretador de grafos (ATN) em tempo real, com lookahead dinâmico e múltiplas simulações. Isso cria overhead. Um parser manual, mesmo gerado por IA, pode ser otimizado para decisões preditivas, backtracking localizado e loops especializados, como o Pratt para expressões, resultando em código muito mais rápido.
O parser novo é mais seguro que o antigo?
Em termos de superfície de ataque, ambos são equivalentes, afinal, precisam aceitar a mesma gramática SQL. Mas o novo parser tem vantagem indireta: sendo mais rápido, reduz janelas de exposição a ataques baseados em consumo de recursos (como DoS via SQL complexo). Além disso, o processo de desenvolvimento com PBT aumenta a confiança na correção, diminuindo risco de falhas sutis.
Fontes
- posthog.comfonte original
- Categoria
- CEVIU Web Dev
- Publicado
- 25 de junho de 2026
- Editoria
- CEVIU Web Dev
