Comparação entre Pesquisa de Texto Completo do PostgreSQL e Elasticsearch
Um único banco de dados ou uma pilha de busca real
O verdadeiro argumento não é se o PostgreSQL pode pesquisar texto ou se o Elasticsearch pode armazenar documentos. Ambos podem. A questão interessante é onde a complexidade da pesquisa deve residir.
A pesquisa de texto completo do PostgreSQL vive dentro de um banco de dados relacional transacional com tsvector, tsquery, dicionários, classificação (ranking) e índices GIN. O Elasticsearch é um mecanismo de pesquisa e análise distribuído construído sobre o Lucene, com analisadores, pontuação BM25, escala baseada em shards (fragmentos), agregações e indexação quase em tempo real.
Essas são filosofias operacionais diferentes antes mesmo de serem listas de funcionalidades diferentes.
Se você está mapeando essa escolha para armazenamento, pipelines e operações, esta visão geral de infraestrutura de dados fornece o contexto do sistema mais amplo.
Sobre o que essa comparação realmente trata
Em um nível baixo, ambos os sistemas dependem de ideias de índices invertidos, mas os empacotam de formas muito diferentes. O PostgreSQL recomenda o GIN como o tipo de índice de pesquisa de texto preferido e o descreve como um índice invertido sobre lexemas em valores tsvector. O Elasticsearch analisa campos text e os indexa para pesquisa de texto completo, distribuindo depois esses índices entre shards e nós para escalabilidade. Na prática, o PostgreSQL parece uma pesquisa embutida em seu banco de dados de aplicação, enquanto o Elasticsearch parece uma plataforma de pesquisa dedicada com seu próprio tempo de execução, ciclo de vida e modelo de escalabilidade.
Esta comparação trata principalmente da pesquisa de texto completo nativa do PostgreSQL mais o auxiliar muito comum pg_trgm para correspondência aproximada. Esse escopo importa porque o ecossistema mais amplo do PostgreSQL está se tornando mais pesado em pesquisa com o tempo. Extensões como RUM adicionam comportamentos de índice mais ricos para pesquisa de frases e varreduras orientadas a classificação, enquanto o PGroonga estende o PostgreSQL com outro caminho de indexação de texto completo. Isso não torna o PostgreSQL nativo igual ao Elasticsearch, mas significa que o limite é menos estático do que muitas comparações antigas assumem.
Minha estrutura de opinião é simples. A pesquisa geralmente é um recurso até se tornar uma superfície de produto. O PostgreSQL tende a vencer enquanto a pesquisa ainda é um recurso. O Elasticsearch tende a vencer quando a pesquisa se torna a primeira coisa que os usuários julgam. Isso tem menos a ver com nomes de marca e mais a ver com onde a lógica de relevância, a política de indexação e a dor operacional são permitidas a viver.
Como funciona a pesquisa de texto completo do PostgreSQL
A pesquisa de texto completo do PostgreSQL começa transformando texto bruto em lexemas. to_tsvector tokeniza o texto, normaliza-o através dos dicionários configurados, remove palavras de parada e armazena os lexemas sobreviventes com posições. setweight permite rotular lexemas de diferentes partes do documento, como título, resumo e corpo, para que essas partes possam influenciar a classificação de forma diferente. O PostgreSQL também suporta várias configurações de idioma predefinidas e permite criar configurações personalizadas com analisadores e dicionários.
Se você quiser uma referência SQL compacta enquanto implementa esses padrões, esta lista de atalhos do PostgreSQL e esta lista de atalhos SQL com os comandos SQL mais úteis são companheiros práticos.
Um padrão de produção típico é uma coluna tsvector gerada armazenada mais um índice GIN. A documentação do PostgreSQL é direta ao afirmar que a pesquisa de texto prática geralmente requer um índice, e mostra explicitamente uma coluna gerada armazenada alimentando um índice GIN. Esse padrão evita a recomputação de to_tsvector durante a verificação e mantém a superfície de consulta limpa.
alter table posts
add column search_vector tsvector
generated always as (
setweight(to_tsvector('english', coalesce(title, '')), 'A') ||
setweight(to_tsvector('english', coalesce(summary, '')), 'B') ||
setweight(to_tsvector('english', coalesce(body, '')), 'D')
) stored;
create index posts_search_idx
on posts using gin (search_vector);
select id,
title,
ts_rank_cd(
search_vector,
websearch_to_tsquery('english', '"query planner" -mysql')
) as rank
from posts
where search_vector @@ websearch_to_tsquery('english', '"query planner" -mysql')
order by rank desc
limit 20;
No lado da consulta, o PostgreSQL oferece vários analisadores porque a entrada do usuário é mais bagunçada do que os blogs de engenharia admitem. to_tsquery é explícito e poderoso. phraseto_tsquery preserva a ordem das palavras com o operador <->. websearch_to_tsquery aceita entrada semelhante a mecanismos de pesquisa, entende frases entre aspas, OR e negação -, e nunca levanta erros de sintaxe em entradas brutas de usuários. O PostgreSQL também suporta correspondência de prefixo anexando * a um lexema em to_tsquery.
A classificação é onde o PostgreSQL nativo mostra tanto sua força quanto seu limite. ts_rank e ts_rank_cd podem usar frequência, proximidade e pesos estruturais, e o modelo de ponderação é surpreendentemente bom para muitas tarefas de pesquisa de aplicação. Ao mesmo tempo, os próprios documentos do PostgreSQL observam que a classificação pode ser cara e que as funções de classificação integradas não usam informações globais. Esse é o limite silencioso, mas importante, da pesquisa de texto completo nativa do PostgreSQL. Ele pode classificar, mas a relevância não é o centro de gravidade do mecanismo.
Quando o PostgreSQL é suficiente para pesquisa de texto completo
O PostgreSQL é suficiente com mais frequência do que os fornecedores dedicados de pesquisa gostariam. É particularmente atraente quando a pesquisa fica muito próxima de linhas transacionais, joins, permissões e escritas recentes. O modelo MVCC do PostgreSQL fornece consistência transacional e leitura baseada em snapshot, então o mesmo banco de dados que aceita a escrita pode responder à pesquisa sem uma janela de atualização estilo Elasticsearch. Quando uma caixa de pesquisa é realmente “encontrar registros dentro do aplicativo que eu acabei de editar”, essa propriedade importa mais do que demonstrações de relevância brilhantes.
Também é suficiente quando a filtragem SQL é metade do recurso. Filtros de status, isolamento de inquilino, estados de publicação, carimbos de data/hora e joins relacionais muitas vezes importam tanto quanto a relevância de palavras-chave em sistemas de linha de negócios. Nesses casos, a pesquisa de texto completo do PostgreSQL se comporta como outro predicado indexado em um plano de consulta relacional, não como uma plataforma separada que precisa ser alimentada e mantida aquecida. Essa é uma arquitetura entediante, e entediante é frequentemente o tipo certo de rápido.
Como o Elasticsearch funciona como mecanismo de pesquisa
O Elasticsearch se apresenta de forma muito diferente. Seus próprios documentos o definem como um mecanismo de pesquisa e análise distribuído, armazenamento de dados escalável e banco de dados vetorial construído sobre Apache Lucene, otimizado para velocidade e relevância em escala de produção e operando quase em tempo real. O Elasticsearch divide cada índice em shards, replica esses shards e os distribui entre nós para aumentar a capacidade de indexação e consulta. É por isso que o Elasticsearch raramente é “apenas um índice”. É uma arquitetura de cluster.
Por baixo dos panos, os analisadores fazem a maior parte do trabalho pesado. Um analisador do Elasticsearch é uma composição de filtros de caracteres, tokenizadores e filtros de tokens. Existem analisadores integrados, analisadores de idioma e analisadores personalizados, e o tratamento de sinônimos é uma parte de primeira classe da análise. Isso significa que o comportamento da pesquisa não é apenas sobre a consulta. Também é sobre como documentos e consultas são normalizados antes que a pontuação comece.
Para uma referência de API prática enquanto implementa esses padrões, esta lista de atalhos do Elasticsearch coleta comandos essenciais e atalhos operacionais.
PUT posts
{
"mappings": {
"properties": {
"title": { "type": "text" },
"summary": { "type": "text" },
"body": { "type": "text" },
"tags": { "type": "keyword" }
}
}
}
GET posts/_search
{
"query": {
"bool": {
"must": [
{
"multi_match": {
"query": "query planner",
"fields": ["title^3", "summary^2", "body"],
"type": "best_fields"
}
}
],
"must_not": [
{ "match": { "body": "mysql" } }
]
}
},
"aggs": {
"by_tag": {
"terms": {
"field": "tags"
}
}
},
"highlight": {
"fields": {
"body": {}
}
}
}
O DSL de Consulta é onde o Elasticsearch começa a sentir-se nativo de pesquisa em vez de parecido com banco de dados. bool combina cláusulas com must, should, filter e must_not. multi_match pode pesquisar através de muitos campos com boosts de campo e modos de execução diferentes como best_fields, most_fields, cross_fields, phrase e bool_prefix. Agregações, destaques e filtros podem todos ficar ao lado da consulta principal na mesma solicitação. BM25 é o modelo de similaridade padrão.
O modelo de frescura também é explícito. O Elasticsearch é quase em tempo real, não imediatamente consistente em pesquisa. Operações recentes tornam-se visíveis à pesquisa quando uma atualização abre um novo segmento, e, por padrão, essa atualização acontece a cada segundo em índices que foram pesquisados recentemente. Os documentos da Elastic também avisam que atualizações são intensivas em recursos e recomendam esperar por atualizações periódicas ou usar refresh=wait_for quando um fluxo de trabalho precisa de visibilidade de pesquisa de leitura-após-escrita. Esse é um contrato muito diferente do PostgreSQL.
Por que o Elasticsearch geralmente classifica melhor a pesquisa complexa
Este é o motivo técnico mais profundo pelo qual muitas equipes eventualmente migram da pesquisa de texto completo do PostgreSQL para o Elasticsearch. As funções de classificação integradas do PostgreSQL não usam informações globais, enquanto o Elasticsearch usa BM25 por padrão e expõe configurações de similaridade específicas de campo, analisadores, formas de consulta multi-campo e um DSL de pesquisa projetado em torno do ajuste de relevância. Uma vez que a pesquisa se torna menos sobre “isso correspondente” e mais sobre “por que esses dez resultados venceram”, o Elasticsearch geralmente tem mais espaço expressivo.
O Elasticsearch também tem um viés claro para documentos desnormalizados. Sua documentação de campo de join avisa explicitamente contra modelar múltiplos níveis de relações para replicar um esquema relacional e recomenda a desnormalização para melhor desempenho de pesquisa. Essa escolha de design explica muita das forças e frustrações do Elasticsearch. Ele não está tentando ser um PostgreSQL com um LIKE mais rápido. Está tentando ser um mecanismo de pesquisa que pode pontuar e recuperar grandes coleções de documentos rapidamente.
Pesquisa de texto completo do PostgreSQL vs Elasticsearch em recursos reais
A tolerância a erros de digitação é onde os dois sistemas divergem drasticamente. O Elasticsearch fornece consultas fuzzy baseadas na distância de edição Levenshtein e também oferece tipos de campo de sugestão e digitação dedicados. A pesquisa de texto completo nativa do PostgreSQL não é tolerante a erros de digitação por si só. A resposta usual do PostgreSQL é pg_trgm, que adiciona operadores de similaridade e suporte a índice para similaridade de trigramas, LIKE e ILIKE. Isso funciona bem, mas é uma estratégia de composição em vez de um conjunto de recursos de mecanismo de pesquisa integrado.
Destaque existe em ambas as pilhas, mas os detalhes de implementação contam uma história. O PostgreSQL usa ts_headline, que pode retornar trechos úteis, mas os documentos observam que ele usa o documento original, pode ser lento e não é garantido seguro para inserção direta em páginas da web. O destaque do Elasticsearch pode usar offsets de postagens ou vetores de termos, o que é especialmente valioso em campos grandes porque evita reanalisar o texto completo para cada solicitação de destaque. Em suma, o PostgreSQL pode destacar, enquanto o Elasticsearch é construído para destacar em escala.
Facetas e analytics de pesquisa são outra linha de falha. O Elasticsearch trata agregações como uma parte de primeira classe do modelo de pesquisa, com agregações de métrica, bucket e pipeline disponíveis diretamente na resposta de pesquisa. O PostgreSQL obviamente pode agregar porque é SQL, mas uma vez que buckets contados, histogramas e analytics de pesquisa composáveis se tornam parte do próprio produto de pesquisa, o Elasticsearch se sente muito mais nativo. A diferença não é capacidade em princípio. É quanto ergonomia de consulta e política de desempenho o mecanismo dedica a essa carga de trabalho.
Autocompletar segue o mesmo padrão. O PostgreSQL pode fazer correspondência de prefixo em to_tsquery, o que é útil e muitas vezes suficiente para ferramentas internas. O Elasticsearch vai além com campos search_as_you_type que automaticamente constroem múltiplos subcampos analisados para conclusão de prefixo e infix, além de sugeridores de conclusão projetados para sugestões rápidas. Essa lacuna é pequena em um painel administrativo e grande em uma superfície de descoberta voltada ao usuário.
O custo operacional importa mais do que prints de benchmark
A pergunta tentadora sobre o mecanismo de pesquisa é: “O Elasticsearch é mais rápido que o PostgreSQL para pesquisa?” A resposta honesta é: “para qual formato de pesquisa?” O Elasticsearch é projetado em torno de shards, réplicas, indexação em lote, política de atualização e gerenciamento de ciclo de vida. Os próprios documentos de produção da Elastic aprofundam na estratégia de sharding, dimensionamento de solicitações em lote, throughput de indexação, intervalos de atualização e ILM. O PostgreSQL evita um segundo cluster, mas a manutenção do GIN não é gratuita. Os documentos do PostgreSQL avisam que inserções GIN podem ser lentas, que a limpeza de listas pendentes pode causar flutuações no tempo de resposta e que a estratégia de autovacuum importa se o índice for atualizado intensamente.
Isso torna a história de desempenho mais matizada do que a maioria dos posts de comparação admite. O Elasticsearch geralmente tem mais espaço para pesquisa lexical grande de top-N, faceting, autocompletar e volume de leitura distribuído porque sua arquitetura é dedicada a essas tarefas. O PostgreSQL frequentemente se sente mais rápido para consultas de aplicação relacional com requisitos de frescura estritos porque não há um segundo datastore, não há fronteira de atualização e não há caminho de sincronização para depurar. O vencedor geralmente é o formato da carga de trabalho, não o print de benchmark. Isso é parcialmente uma inferência, mas segue diretamente do modelo transacional MVCC do PostgreSQL e do design baseado em shards quase em tempo real do Elasticsearch.
Dados transacionais e índices de pesquisa devem viver no mesmo sistema? Quando a relevância da pesquisa é modesta, mas frescura, permissões e verdade transacional são críticos, o design do mesmo sistema tem vantagens óbvias. Quando qualidade de pesquisa, faceting, política de sinônimos, tolerância a erros de digitação e escala de pesquisa horizontal tornam-se preocupações de produto de primeira classe, um segundo sistema começa a parecer justificado. A própria orientação de dimensionamento de sharding da Elasticsearch diz que não há uma estratégia única para todos e recomenda fazer benchmark de dados de produção em hardware de produção. Essa frase captura a compensação perfeitamente. O Elasticsearch compra espaço pedindo que você opere uma arquitetura mais específica de pesquisa.
O veredito prático
A pesquisa de texto completo do PostgreSQL vence os primeiros 80 por cento surpreendentemente com frequência. Ele suporta tokenização, palavras de parada, derivação (stemming), consultas de frases, pesos, classificação, destaque, vetores de pesquisa gerados, índices GIN e auxiliares de similaridade baseados em trigramas. Combinado com a semântica transacional do PostgreSQL, ele dá a muitas aplicações uma pilha de pesquisa que é simples, atual e próxima dos dados. Para escritórios de back-office de SaaS, ferramentas internas, sites de conteúdo moderado e pesquisa nativa de aplicativos, essa combinação é difícil de descartar.
O Elasticsearch torna-se persuasivo quando a pesquisa não é meramente um filtro, mas uma superfície de produto. BM25 por padrão, analisadores personalizados, filtros de sinônimos, consultas fuzzy, classificação multi-campo, agregações, opções de autocompletar dedicadas, estratégias de destaque de campos grandes e escalabilidade baseada em shards distribuídos não são recursos laterais. São a razão pela qual o mecanismo existe. É por isso que as comparações do Elasticsearch que focam apenas na latência bruta geralmente perdem o ponto. A maior diferença é quanta lógica de produto de pesquisa o mecanismo está disposto a assumir.
O modelo mental mais limpo é este. A pesquisa de texto completo do PostgreSQL é excelente quando a pesquisa pertence ao banco de dados. O Elasticsearch é excelente quando o banco de dados deve alimentar uma plataforma de pesquisa. A maioria das equipes foca demais em velocidade e foca pouco nos modos de falha. A troca real é onde o ajuste de relevância, a frescura de dados e a complexidade operacional são permitidos a residir.
