PlanetScale lança extensão de busca de texto para Postgres, e ParadeDB rebate benchmark em duas semanas

O que a PlanetScale lançou, e por que isso chama atenção

Duas semanas antes do dia 1º de outubro de 2026, a PlanetScale divulgou o TIN, uma extensão de busca full-text para Postgres↳PostgreSQL11 conteúdosPostgreSQL via SSL com GolangData · abr 20195 itens legais sobre data types do PostgreSQLData · mar 20195 serviços gratuitos na cloud para bancos de dados PostgresData · fev 2025Ver tudo em Data →. O detalhe curioso é que a PlanetScale é conhecida historicamente pelo MySQL (via Vitess), não pelo Postgres. O TIN, porém, é especificamente uma extensão para o banco da elefantina, e o post de lançamento trouxe benchmarks mostrando vantagem expressiva sobre o ParadeDB, extensão rival de busca em Postgres baseada na biblioteca Tantivy.

Segundo o relato publicado por Ming Ying, engenheiro do ParadeDB, no blog do projeto (republicado no agregador Planet PostgreSQL), o TIN apareceu com números fortes: pelo menos 8 vezes mais rápido que o ParadeDB 0.25 em busca ranqueada por BM25 e em contagem de documentos, usando o mesmo dataset do StackExchange.

O TIN é rápido (pelo menos 8 vezes mais rápido que o ParadeDB 0.25 em todos os benchmarks da PlanetScale).

TIN is fast (at least 8x faster than ParadeDB 0.25 in every PlanetScale benchmark).Ming Ying, engenheiro do ParadeDB

Esse tipo de gap costuma indicar diferença de arquitetura, não só de implementação. E é exatamente o que o post do TIN alegava: usar o ctid nativo do Postgres como identificador de documento, eliminando um mapeamento intermediário que o ParadeDB precisa manter.

Como o ParadeDB fechou a diferença sem mudar de arquitetura

O time do ParadeDB decidiu investigar antes de aceitar a tese do ctid como causa raiz. Rodando EXPLAIN (ANALYZE, BUFFERS) sobre uma consulta simples de BM25 Top K, encontraram algo revelador: 83% dos acessos a páginas do Postgres eram para ler fieldnorms, a estrutura que normaliza o score pelo tamanho do documento.

O problema não era o tamanho dos fieldnorms (cada um ocupa um único byte), e sim a localidade de acesso: o Tantivy guarda os fieldnorms num array indexado por DocId, separado das postings lists, o que gera leitura espalhada pela página. A correção foi simples em conceito: duplicar o array de fieldnorms junto de cada postings list, na mesma ordem dos DocId, trocando leitura aleatória por leitura sequencial.

O resultado: os acessos a páginas de fieldnorms caíram de cerca de 1.500 para 30 na mesma consulta. O custo é armazenamento adicional (o índice de 28,7 milhões de documentos do Hacker News cresceu cerca de 9%), mas o ganho de I/O compensou de sobra.

A segunda otimização: trocar o algoritmo de poda

Mesmo depois da correção de fieldnorms, consultas de disjunção com muitos termos (do tipo termoA OR termoB OR termoC...) continuavam lentas. O perfil apontou o gargalo no Blockmax WAND, o algoritmo que o Tantivy usa para pular blocos de postings que não podem superar o score mínimo do Top K atual.

Existem duas famílias de algoritmo de poda: WAND, que pula mais mas gasta mais CPU decidindo o que pular, e MAXSCORE, que pula menos mas com menos overhead. Quando a consulta tem muitos termos, o custo do WAND cresce e passa a pesar mais que o ganho. O Lucene já havia passado por essa migração em 2023, adotando MAXSCORE para certos formatos de consulta.

O ParadeDB implementou um seletor simples: usar MAXSCORE para disjunções com três ou mais termos e postings densas, e manter WAND para o resto. Numa consulta de dez termos, a latência p50 caiu cerca de 6 vezes e a p95 cerca de 8 vezes — o suficiente para o ParadeDB passar a ficar 2 vezes mais rápido que o TIN no dataset do Hacker News.

O benchmark original tinha dois problemas de configuração

Além das otimizações de código, o time do ParadeDB encontrou dois vieses na forma como o benchmark da PlanetScale foi montado.

O primeiro é sintático: as consultas usaram o operador @@@ do ParadeDB sem qualificar o campo de busca (<query> em vez de <campo>:<query>). No dataset do StackExchange, isso faz o ParadeDB varrer duas colunas de texto indexadas por consulta, enquanto o TIN varria apenas uma. Trocar para os operadores nativos |||, &&& e ### resolveu a distorção.

O segundo é mais interessante para quem avalia correção, não só velocidade. O TIN usa uma técnica chamada dense-term elision: em tempo de consulta, ignora o score de qualquer termo que apareça em mais de 10% do corpus (parâmetro dense_ratio). É um atalho de performance, mas tem preço.

Em resumo: quando o time do ParadeDB mediu o impacto dessa elisão sobre a precisão do ranking, os números preocupam quem trata busca como algo que precisa estar certo, não só rápido:

Em 6,4% das consultas, nenhum dos resultados do Top 10 batia com o BM25 exato. E parte das queries de teste do próprio benchmark eram sequências de palavras comuns ("is it", "to a"), justamente o cenário onde a elisão mais distorce o ranking.

A comparação final: BM25 exato contra BM25 exato

Com as correções de configuração e otimização aplicadas, o ParadeDB republicou os números comparando BM25 exato nos dois lados, além do cenário com elisão habilitada no TIN (como no benchmark original):

Ou seja: quando os dois mecanismos calculam o mesmo score, o ParadeDB passa à frente. A vantagem do TIN só aparece quando ele está respondendo uma pergunta ligeiramente diferente (BM25 aproximado).

ctid contra DocId: a discussão que fica em aberto

A tese central do TIN era que usar o ctid do Postgres como identificador de documento é superior por eliminar uma tradução. O ParadeDB discorda, e o argumento técnico interessa a quem modela índice de busca sobre banco relacional.

Um ctid concatena número de bloco (na casa dos milhões) com posição de tupla (no máximo 291), dois domínios numéricos diferentes dentro do mesmo inteiro de 48 bits. Isso compacta pior do que um DocId denso, sequencial, de 32 bits, que é o padrão da maioria dos motores de busca (inclusive o Lucene). Compressão de postings lists depende diretamente disso.

Há ainda o problema de armazenamento colunar, necessário para ordenar por campo, aplicar filtro de faixa ou gerar facetas, três operações comuns em busca de produto. Com DocId denso, o documento 42 corresponde direto à linha 42 de cada coluna. Com ctid, é preciso mapear a posição física (bloco, slot) para uma posição colunar antes de buscar qualquer atributo, o mesmo custo de tradução que o TIN alega ter eliminado, só que na direção inversa.

O que muda para quem decide entre Postgres nativo e Elasticsearch

Para quem avalia tirar o Elasticsearch da stack e concentrar busca full-text dentro do próprio Postgres, o episódio deixa três lições práticas.

• Benchmark de lançamento é ponto de partida, não veredito. Em duas semanas o concorrente fechou uma diferença de 8x sem mudar de arquitetura, só ajustando locality de dados e trocando algoritmo de poda. Releia a configuração (dense_ratio, qualificação de campo, stopwords) antes de decidir qualquer migração.
• Correção tem peso maior que throughput. Um ranking BM25 aproximado pode bastar para boa parte dos casos de uso, mas a decisão de usar elisão de termos comuns deve ser explícita e documentada, não uma configuração padrão escondida no benchmark de marketing.
• Abertura do código importa na avaliação. O ParadeDB é extensão open source↳Open source71 conteúdosComo o Open Source Está Liberando o Poder da Automação para TodosDev (Back & Front) · out 2025Código aberto: programadores criam software da NASA sem saberDev (Back & Front) · abr 2021N8N: O que é a ferramenta open source que está revolucionando a automação em TI?Dev (Back & Front) · dez 2025Ver tudo em Dev (Back & Front) → que roda em qualquer Postgres autogerenciado; o TIN, até esta publicação, só existe dentro da infraestrutura gerenciada da PlanetScale, o que limita a portabilidade para quem já opera o próprio cluster.

O ParadeDB já cortou um release candidate, o 0.26.0-rc.2, com essas otimizações, e promete a versão estável 0.26.0 na semana seguinte à publicação. As mudanças são compatíveis com versões anteriores, mas exigem reindexação para herdar os ganhos de locality. O post de Ming Ying é a Parte I de uma série; a Parte II deve tratar das otimizações em consultas de contagem (COUNT), que usam caminho de código diferente do Top K por BM25.

Fonte: Planet PostgreSQL