Quem mais se beneficia de Full-Text

Objetivos

Nesta aula você vai:

• Comparar FTS embutido em SGBDs versus motores dedicados
• Escolher entre MariaDB, SQL Server, OpenSearch, Meilisearch e Typesense por contexto
• Montar uma matriz de decisão por volume, relevância, equipe e custo

Introdução

Full-text não é um produto — é uma capacidade. Às vezes mora no banco (MariaDB, SQL Server, Postgres, SQLite/D1). Às vezes exige motor dedicado (OpenSearch, Meilisearch, Typesense). Esta aula fecha o panorama “outros bancos” com uma matriz pragmática de benefício.

Conteúdo

Duas famílias

1. FTS no SGBD: menos peças, transação próxima dos dados, relevância lexical “boa o suficiente”.
2. Motor dedicado: analyzers, facetas, typo-tolerance, escala de QPS de busca, times de search/platform.

Matriz resumida

MariaDB

FULLTEXT em InnoDB com MATCH ... AGAINST (modos NATURAL LANGUAGE / BOOLEAN). Benefício alto se o app já é MariaDB e a busca é funcionalidade auxiliar. Benefício baixo se busca é o produto (marketplace global).

SQL Server

Full-Text Engine com catálogos, stoplists e CONTAINS/FREETEXT. Forte em empresas Windows/.NET com DBA. Integração com FileTable/documentos. Custo de licenciamento e operação entram na decisão.

Elasticsearch / OpenSearch

Quem mais se beneficia: marketplaces, logs + busca, portais com facetas, multi-tenant com analyzers custom. Exige capacidade de cluster, mapping e reindex. OpenSearch é fork compatível comum em cloud.

Meilisearch e Typesense

Quem mais se beneficia: startups e produtos que querem UX de busca moderna (typos, ranking sensato) sem equipe de Lucene. Menos peças que um cluster ES. Avalie: persistência, HA, multitenancy e requisitos de compliance.

Critérios de decisão (lista de verificação rápida)

1. Volume de docs e QPS de busca — SGBD aguenta?
2. Relevância — lexical basta ou precisa typo/sinônimos/semântica?
3. Facetas / filtros combinados — motor dedicado brilha.
4. Equipe — DBA SQL vs platform search vs “só o app”.
5. Custo — licença + RAM + reindex + on-call.
6. Localidade dos dados — edge (D1) vs região única vs multi-região.

Busca auxiliar + SQL já existe     → FTS do SGBD / FTS5
UX de busca é diferencial + time pequeno → Meilisearch / Typesense
Escala + facetas + analytics       → OpenSearch / Elasticsearch
Significado / similaridade         → Vetores (ex.: Vectorize) ± lexical

Exemplos práticos

-- MariaDB (ilustrativo)
CREATE TABLE posts (
  id INT PRIMARY KEY AUTO_INCREMENT,
  title VARCHAR(200),
  body TEXT,
  FULLTEXT KEY ft_posts (title, body)
) ENGINE=InnoDB;

SELECT id, title,
       MATCH(title, body) AGAINST ('cloudflare D1' IN NATURAL LANGUAGE MODE) AS score
FROM posts
WHERE MATCH(title, body) AGAINST ('cloudflare D1' IN NATURAL LANGUAGE MODE)
ORDER BY score DESC
LIMIT 20;

-- SQL Server (ilustrativo)
SELECT id, title
FROM dbo.Articles
WHERE CONTAINS((title, body), 'FTS5 AND D1')
ORDER BY id DESC;

// Meilisearch — indexação e busca
await index.addDocuments([
  { id: 1, title: 'FTS5 no D1', body: 'Busca na edge' },
]);
const hits = await index.search('busca edge', { limit: 20 });

Problemas e como resolver

Resumo

Benefício máximo vem do encaixe: FTS no SGBD quando a busca é auxiliar; Meilisearch/Typesense quando a UX importa e o time é enxuto; OpenSearch/ES quando escala e facetas dominam. A próxima trilha foca medição, antipadrões e checklist de arquitetura em produção.