OpenSearch y alternativas a ElasticSearch en 2026
Si en 2020 alguien te decía “usá ElasticSearch para búsqueda”, era el consejo correcto. En 2026, la respuesta es “depende”. Y las alternativas son más interesantes que nunca.
El problema con ElasticSearch
Elastic NV cambió la licencia de Elasticsearch a SSPL/ELv2 en 2021. AWS respondió forkando a OpenSearch. Dos años de guerra legal después, la situación es:
- Elasticsearch (Elastic NV): SSPL/ELv2. Gratis para uso interno, pago para ofrecerlo como servicio.
- OpenSearch (AWS): Apache 2.0. Fork de Elasticsearch 7.10.2.
- Ambos comparten ~80% del código base y la API es compatible en la superficie.
Pero la pregunta real no es “Elasticsearch vs OpenSearch”. Es: ¿necesitás un motor de búsqueda dedicado?
El espectro de opciones
1. PostgreSQL + pgvector (la opción aburrida que funciona)
Si tu búsqueda es “textos en español con filtros por fecha y categoría”, PostgreSQL con tsvector y pg_trgm te da el 80% de lo que ElasticSearch ofrece, con una fracción de la complejidad operativa.
-- Búsqueda full-text en PostgreSQL
SELECT id, title, ts_rank(search_vector, query) AS rank
FROM articles, plainto_tsquery('spanish', 'arquitectura cloud') AS query
WHERE search_vector @@ query
ORDER BY rank DESC
LIMIT 20;Con pgvector agregás búsqueda semántica (embeddings). Para la mayoría de los blogs, docs técnicos, y catálogos de productos, PostgreSQL es suficiente.
Cuándo usar: < 1M documentos, búsqueda full-text + filtros simples, ya usás PostgreSQL.
2. Meilisearch (la opción developer-friendly)
Meilisearch es Rust, rápido, y la API es ridículamente simple. No tiene la complejidad de mapping de ElasticSearch. Configurás un índice, mandás documentos, buscás.
# Indexar
curl -X POST 'http://localhost:7700/indexes/articles/documents' \
-H 'Content-Type: application/json' \
--data-binary @articles.json
# Buscar
curl 'http://localhost:7700/indexes/articles/search?q=redis'Meilisearch maneja typo-tolerance, faceting, y filtering out of the box. No necesitás configurar analyzers, tokenizers, ni mappings complejos. Funciona.
Cuándo usar: < 10M documentos, búsqueda para usuarios finales, necesitás results en < 50ms, no necesitás aggregations complejas.
3. Typesense (el punto medio)
Typesense es C++, typo-tolerante, y tiene features que Meilisearch no tiene: geo-search, conjunctive faceting, y un modelo de clustering más maduro. La API es similar en simplicidad.
Cuándo usar: necesitás geo-búsqueda, tenés entre 1M-50M documentos, querés typo-tolerance sin configurar nada.
4. OpenSearch (cuando necesitás el poder de Elastic)
Si venís de ElasticSearch y tenés queries complejas, aggregations, o un equipo que ya conoce el ecosistema, OpenSearch es la migración natural. La API es compatible, los índices se migran con snapshot/restore, y las queries DSL funcionan igual.
Cuándo usar: ya tenés ElasticSearch, necesitás aggregations complejas, tenés > 50M documentos, tu equipo conoce el stack.
Matriz de decisión
| Criterio | PostgreSQL | Meilisearch | Typesense | OpenSearch |
|---|---|---|---|---|
| Complejidad operativa | Mínima | Mínima | Baja | Alta |
| Full-text quality | Buena | Excelente | Excelente | Excelente |
| Typo tolerance | No | Sí | Sí | Configurable |
| Escala práctica | < 1M docs | < 10M docs | < 50M docs | Ilimitada |
| Aggregations | LIMIT | No | Básicas | Completo |
| Búsqueda semántica | pgvector | No | No | Plugins |
| Coste infra | $0 (ya lo tenés) | $ | $ | $$$ |
Mi recomendación para 2026
- Blog / docs técnicas: PostgreSQL full-text o Meilisearch. No necesitás más.
- E-commerce con facets: Typesense o Meilisearch.
- Plataforma enterprise con search complejo: OpenSearch (o quedate en Elastic si ya lo tenés).
- Búsqueda semántica / RAG: PostgreSQL + pgvector para empezar. Si escala, evaluá Qdrant o Weaviate.
La lección: antes de agregar ElasticSearch a tu stack, preguntate si PostgreSQL no resuelve el 80% del problema. La respuesta casi siempre es sí.