Sabe aquela busca que demora uma eternidade pra retornar? Ou pior, que volta com um monte de coisa que não tem nada a ver com o que você digitou?
Pois é. Provavelmente tem um LIKE '%produto%' na origem disso tudo.
O problema do LIKE
O detalhe está no % do começo. Com o wildcard na frente, o banco não consegue usar o índice: ele lê linha por linha até achar o que você quer. Um LIKE 'produto%', sem o % inicial, usa índice numa boa — o vilão é a busca "que contém", não o LIKE em si.
Em um projeto pequeno, com poucos dados, você nem nota. Mas conforme a aplicação cresce e os acessos aumentam, isso vira o caminho mais rápido pra sua performance ir por água abaixo.
Com LIKE, o banco lê cada linha. Com FTS, vai direto ao índice.
Pensa comigo: imagine que você precisasse ler um dicionário inteiro do começo ao fim só pra encontrar uma palavra. É exatamente isso que o banco está fazendo cada vez que essa query roda.
O alerta de ouro: não use o que você não precisa
Muita calma nessa hora.
Se você está criando um projeto paralelo, um MVP ou uma aplicação com poucos usuários, esquece o Elasticsearch e qualquer implementação complexa de FTS. O custo de manutenção, infraestrutura e sincronização de dados é alto demais pra um cenário que não exige essa robustez.
O LIKE do seu banco relacional está ótimo pro começo. Não tente aplicar arquitetura do iFood num sistema de agendamento de barbearia!
Antes de trocar de ferramenta, indexe
E tem um degrau no meio do caminho que muita gente pula. No Postgres, dá pra fazer aquele mesmo LIKE '%produto%' usar índice:
CREATE EXTENSION pg_trgm;CREATE INDEX idx_produtos_nome ON produtos USING gin (nome gin_trgm_ops);
Pronto. Mesma query, sem mudar uma linha da aplicação, sem subir serviço nenhum — e ainda vem tolerância a erro de digitação de brinde. Na maioria dos projetos, a conversa acaba aqui.
O preço: o índice ocupa espaço e deixa INSERT e UPDATE um pouco mais lentos. Quase sempre compensa, mas é bom saber que tem troca.
A solução: Full-Text Search (para sistemas de alta escala)
Quando falamos de milhares ou milhões de acessos e buscas complexas, o jogo muda. O Full-Text Search (FTS) resolve isso com uma estrutura chamada índice invertido. Em vez de varrer o texto, o sistema cria antecipadamente um mapa de palavras, igualzinho ao índice remissivo no final de um livro.
O índice invertido mapeia cada palavra para os documentos onde ela aparece. Na hora da busca, é só consultar o mapa.
Então quando o usuário digita "fone bluetooth sem fio", o sistema não sai varrendo a tabela de produtos linha por linha. Ele consulta o índice e devolve o resultado em milissegundos.
Duas coisas pra saber antes de migrar: FTS trabalha com palavras inteiras, não com pedaços — buscar "bluet" não acha "bluetooth" como o LIKE achava. E, em português, sem configurar o unaccent, "acucar" não encontra "açúcar".
Quando ir além do básico?
O PostgreSQL tem suporte nativo a FTS e vai longe, muito mais longe do que a maioria imagina. Você sai dele quando precisa de um recurso que ele não tem, não porque a tabela cresceu.
Aí entram os motores especializados: Meilisearch e Typesense se você quer resultado rápido sem operar um cluster, Elasticsearch quando a necessidade é realmente grande.
Os principais benefícios que você ganha:
- Fuzzy search: tolerância a erros de digitação. O usuário pesquisou "notebbok gammer"? Ele ainda encontra o que precisa.
- Relevância: o resultado vem ordenado por quem casa melhor com a busca. Título pesa mais que descrição, e quem tem os dois termos aparece antes de quem tem só um.
- Performance: latência baixíssima mesmo com milhões de registros e alta concorrência.
Conclusão
Se a sua aplicação exige uma busca rápida e inteligente sob alta concorrência, migrar pra um motor de Full-Text Search é um divisor de águas.
Só não esquece: a melhor arquitetura é aquela que atende aos requisitos do seu momento. Não suba a complexidade antes de ter o problema de escala que a justifique. Primeiro faça funcionar, depois você vai apertando os parafusos.
Dica bônus: quer manter seus dados do banco relacional sincronizados com a ferramenta de busca em tempo real? Pesquisa sobre CDC (Change Data Capture). Só lembra que isso é mais um sistema pra manter de pé — e mais um motivo pra adiar a migração enquanto um índice no seu banco ainda dá conta.
Dica bônus: quer manter seus dados do banco relacional sincronizados com a ferramenta de busca em tempo real? Pesquisa sobre CDC (Change Data Capture). Você vai agradecer depois.