OpenSearch vs Meilisearch vs Typesense: qual escolher
- ⬜🔬 Elasticsearch internals: Lucene, segments, shards, refresh(Search & Information Retrieval Profundo)
Recomendamos completar os pré-requisitos antes de seguir, mas nada te impede de continuar.
Três engines, três filosofias
OpenSearch, Meilisearch e Typesense são os três engines open source mais escolhidos em 2026 fora do Elasticsearch. Cada um nasceu para resolver um problema diferente:
- OpenSearch — fork da AWS, identidade próxima do ES. Para times que precisam de engine completa com agregações, observability, security analytics, e querem licença permissiva (Apache 2.0).
- Meilisearch — instant search com typo tolerance, escrito em Rust. Single binary, defaults perfeitos para e-commerce e documentação. Adicionou vector e hybrid em 2024.
- Typesense — instant search com foco em faceted search, escrito em C++. Single binary, latência sub-50ms consistente, GraphQL-like query DSL.
Documentações oficiais: opensearch.org, meilisearch.com/docs, typesense.org/docs. Para benchmarks independentes, ver MTEB (Massive Text Embedding Benchmark) para retrieval e o blog post anual de Vespa sobre large-scale IR.
Comparativo de alto nível
| Critério | OpenSearch | Meilisearch | Typesense |
|---|---|---|---|
| Linguagem | Java (JVM) | Rust | C++ |
| Engine de IR | Apache Lucene (fork ES 7.10) | Próprio (charabia, hnswlib) | Próprio (forwardindex + posting list) |
| Setup mínimo | Cluster de 3 nós típico, JVM tuning | Single binary, ~1 min | Single binary, ~1 min |
| Typo tolerance | Manual (fuzzy queries) | Default, configurável por threshold | Default, configurável (num_typos) |
| Faceted search | Aggregations, requer tuning | Nativo (filterable attributes) | Nativo (best-in-class) |
| Vector search | kNN com Lucene HNSW | hnswlib, hybrid com semantic_ratio | HNSW, hybrid via vector_query |
| Sharding | Nativo, automático | Não tem (single node) — v2 promete | Cluster com raft, sharding manual |
| Linguagem da query | Query DSL JSON | REST simples + filtros estilo SQL | REST + GraphQL-like |
| Latência p99 | 20-200 ms (depende de cluster) | 5-50 ms | 5-30 ms |
| Escala típica | 10⁸+ docs | 10⁷-10⁸ docs | 10⁷-10⁸ docs |
| Licença | Apache 2.0 | MIT | GPL v3 (Apache 2.0 para client SDKs) |
| Managed cloud | AWS OpenSearch Service, Aiven, Bonsai | Meilisearch Cloud | Typesense Cloud |
OpenSearch: a evolução do ES forkado
OpenSearch é praticamente um ES 7.10 com 5 anos de divergência. O coração ainda é Lucene, segments imutáveis, refresh interval, translog, sharding. A REST API é altamente compatível com ES 7.x. Diferenças notáveis em 2026:
Se você está em AWS, OpenSearch Service é a opção default — managed, integrado, IAM-native. Se está em GCP/Azure ou self-hosted, Elasticsearch managed (Elastic Cloud) ou OpenSearch self-hosted são alternativas igualmente válidas. A licença é hoje menos diferencial do que a integração com seu cloud provider.
Meilisearch: search em Rust
Meilisearch nasceu em 2018 com uma promessa simples: search-as-you-type sub-50ms com typo tolerance e zero configuração. Escrito em Rust, single binary, defaults sensatos. Em 2024 adicionou vector + hybrid. Hoje é escolha popular para SaaS B2B, documentação, e e-commerce médio.
# Setup em 30 segundos
docker run -p 7700:7700 getmeili/meilisearch:v1.10
# Indexar
curl -X POST 'http://localhost:7700/indexes/produtos/documents' \
-H 'Content-Type: application/json' \
--data-binary '[
{ "id": 1, "nome": "Notebook Dell XPS 13", "preco": 7990, "marca": "Dell" },
{ "id": 2, "nome": "MacBook Pro M4", "preco": 14990, "marca": "Apple" }
]'
# Buscar com typo tolerance
curl 'http://localhost:7700/indexes/produtos/search?q=notbook'
# → Encontra "Notebook Dell XPS 13" mesmo com typo
# Configurar facetable attributes
curl -X POST 'http://localhost:7700/indexes/produtos/settings/filterable-attributes' \
-H 'Content-Type: application/json' \
--data-binary '["marca", "preco"]'
# Faceted search com filtro
curl 'http://localhost:7700/indexes/produtos/search' \
-H 'Content-Type: application/json' \
--data-binary '{"q":"laptop", "filter":"preco < 10000", "facets":["marca"]}'Em produção: Meilisearch single-node aguenta tranquilamente catálogos de 10-50M docs com p99 < 50ms. Para mais, espere v2 com sharding (em desenvolvimento em 2026) ou migre para Elasticsearch/Qdrant.
Typesense: faceted search rei
Typesense foi criado por Jason Bourasaw em 2017 explicitamente como "Algolia open source". Escrito em C++, focado em latência consistente e faceted search excepcional. Hoje é favorito de e-commerce e documentação dev-first (Hashicorp, AlgoliaDocs, vários SaaS usam Typesense).
# Setup
docker run -p 8108:8108 -e TYPESENSE_API_KEY=xyz \
-e TYPESENSE_DATA_DIR=/data \
typesense/typesense:0.27.0
# Criar schema (esquema explícito, similar a ES mapping)
curl 'http://localhost:8108/collections' \
-X POST -H 'X-TYPESENSE-API-KEY: xyz' \
-H 'Content-Type: application/json' \
-d '{
"name": "produtos",
"fields": [
{"name":"nome", "type":"string"},
{"name":"marca", "type":"string", "facet": true},
{"name":"preco", "type":"float", "facet": true},
{"name":"embedding", "type":"float[]", "num_dim": 384,
"embed": {"from": ["nome"], "model_config": {"model_name": "ts/all-MiniLM-L12-v2"}}}
]
}'
# Indexar
curl 'http://localhost:8108/collections/produtos/documents' \
-X POST -H 'X-TYPESENSE-API-KEY: xyz' \
-d '{"id":"1","nome":"Notebook Dell XPS 13","marca":"Dell","preco":7990}'
# Hybrid search (BM25 + vector)
curl 'http://localhost:8108/collections/produtos/documents/search?q=laptop+leve&\
query_by=nome,embedding&\
prefix=true&\
num_typos=2&\
facet_by=marca&\
filter_by=preco:<10000'Diferencial Typesense: auto-embedding. Você define no schema e ele gera embeddings automaticamente no índice. Não precisa de pipeline separado de embeddings. Para casos simples, isso elimina toda complexidade de ETL.
Latência: benchmarks reais (catálogo 1M produtos)
Benchmark: catálogo 1M produtos, hardware c6i.2xlarge, query simples
=====================================================================
OpenSearch (single node, default config)
p50: 25 ms p99: 120 ms QPS: ~800
+ agregação por categoria adiciona ~20ms
Meilisearch (v1.10, single binary)
p50: 4 ms p99: 18 ms QPS: ~3500
+ facets ~2ms a mais
Typesense (v0.27, single node)
p50: 3 ms p99: 12 ms QPS: ~4200
+ facets ~1ms a mais
Observações:
- ES/OS são "engines completas" — overhead intrínseco
- MS/TS são single-purpose — overhead mínimo
- Em escala 10M+ docs com agregações pesadas, ES/OS escalam linear; MS/TS começam a apertar
- p99 baixo e consistente é vantagem real de MS/TS para UX de instant searchQual é o principal eixo que separa esses mecanismos de busca?
Vector e hybrid search nos três
| Capacidade | OpenSearch | Meilisearch | Typesense |
|---|---|---|---|
| Vector field nativo | ✅ knn_vector (Lucene HNSW) | ✅ embedder + hnswlib | ✅ float[] + num_dim |
| Auto-embedding na ingestão | 🟡 via Neural Search plugin | ✅ Embedder via OpenAI/HF/REST | ✅ Built-in com modelo local |
| Hybrid (BM25 + vector) | ✅ neural sparse + dense, RRF | ✅ semantic_ratio configurável | ✅ vector_query + text_query |
| Reranker integrado | 🟡 ML Commons (BGE, custom) | ❌ external | ❌ external |
| Max dim suportada | ~16k | ~4096 | ~16k |
| Quantização (int8/bin) | ✅ via Lucene | 🟡 Roadmap | 🟡 Beta |
Importante: vector dentro desses engines de search é "bom o suficiente" para 10M-100M vetores. Para bilhões de vetores com requisitos de QPS extremo, vector DBs dedicadas (Qdrant, Weaviate, Milvus) ainda vencem em memória, throughput e features avançadas (named vectors, payload-filtered HNSW, multi-tenant).
Decisão prática: qual escolher
📋 E-commerce com catálogo 100k-10M produtos, instant search obrigatório
Setup minutos vs dias; Typo tolerance e faceted nativos (UX de instant search default); p99 < 50ms consistente sem cluster tuning; Auto-embedding simplifica RAG/hybrid
Alt: Algolia — managed, melhor DX, mas caro em escala
Alt: Elasticsearch/OpenSearch — overkill aqui, mas se já tem cluster, reusa
📋 Log analytics, observability, SIEM, agregações complexas
Lucene + agregações ricas (date_histogram, terms, percentiles, cardinality); ILM/rollover para time-series; Plugins: Kibana, Logstash, Beats, Security Analytics; Escala horizontal real (10⁹+ docs)
Alt: ClickHouse — colunar, agregações brutalmente rápidas, mas full-text é segundário
Alt: Loki/Grafana — log-specific, custo menor mas features de search limitadas
📋 Documentação técnica, busca em docs internos, knowledge base
Setup trivial em single container; Hybrid search nativo (BM25 + dense); Embedders integrados (OpenAI, HF, Cohere); Tipograma e prefix matching default
Alt: Typesense — equivalente, depende mais de preferência da equipe
Alt: pgvector + Postgres FTS — se já tem Postgres e quer evitar mais um serviço
Custo operacional comparado
Perguntas frequentes
❓ Meilisearch suporta cluster?
❓ Typesense escala para bilhões de docs?
❓ Migrar de ES para OpenSearch é trivial?
❓ Posso usar Meilisearch ou Typesense para RAG?
Resumo executivo
Não existe "melhor engine". Existe melhor encaixe para seu caso. OpenSearch para engines completas com agregações e escala; Meilisearch e Typesense para instant search com UX premium e setup simples.
Próximo módulo: hybrid search profundo — como combinar BM25 + dense + cross-encoder via Reciprocal Rank Fusion e atingir state-of-the-art em retrieval.
Fixando
Quando o mecanismo mais completo se justifica apesar do custo operacional?
Qual é o custo escondido de escolher o mecanismo mais poderoso sem necessidade?
Terminou de ler?
Marcar como concluído registra o XP, mantém sua sequência e coloca 3 cartas deste módulo na fila de revisão espaçada.
Próximos passos sugeridos
Temas deste módulo
Discussão
Carregando comentários…