La gestión de logs y la observabilidad han dejado de ser un problema de «guardar texto y buscarlo rápido». En 2026, el reto real es económico y arquitectónico: ingerir volúmenes crecientes, retener datos durante meses, correlacionar logs con métricas y trazas, y responder durante un incidente sin que el coste se dispare.
Durante años, Elasticsearch fue la opción dominante. Después llegaron OpenSearch, Loki, Quickwit y, con mucha fuerza, ClickHouse como backend analítico. Todas pueden resolver una parte del problema, pero no optimizan para lo mismo. La decisión senior no debería ser «cuál es más rápido» en abstracto, sino qué preguntas hará el equipo, qué retención necesita y cuánta complejidad puede operar.
El estándar histórico: Elasticsearch y OpenSearch
OpenSearch nace como fork open source de Elasticsearch y conserva el modelo mental más familiar para muchos equipos: índices, shards, réplicas, mappings, Query DSL, agregaciones y una experiencia full-text madura. Si tu organización ya viene de Elasticsearch, es la transición más directa.
Arquitectónicamente se apoya en Apache Lucene. Cada índice se divide en shards; cada shard mantiene segmentos e índices invertidos; el clúster coordina escrituras, réplicas, búsquedas distribuidas y agregaciones. Esto da mucha potencia, pero también una huella operativa clara: JVM, heap sizing, merges, tiers hot/warm/cold y tuning de mappings.
En logs, OpenSearch brilla cuando necesitas búsquedas textuales expresivas, filtros ricos, agregaciones, dashboards maduros, tooling existente o casos cercanos a SIEM. El coste aparece cuando el volumen crece: indexar mucho contenido permite buscar rápido, pero consume almacenamiento y memoria.
En 2026 hay que tener en cuenta además la rama 3.x. OpenSearch 3.0 introdujo cambios relevantes como Lucene 10 y JVM 21, además de mejoras de rendimiento y funcionalidades de búsqueda vectorial. Es una señal de vitalidad del proyecto, pero también exige planificar upgrades con más cuidado que en un stack puramente stateless.
Loki: observabilidad centrada en eficiencia
Grafana Loki adopta una filosofía distinta: no indexar el contenido completo de los logs, sino las etiquetas. En la práctica se parece más a «Prometheus para logs» que a Elasticsearch: consultas por labels y filtros posteriores sobre las líneas con LogQL.
Su almacenamiento se basa en chunks comprimidos y un índice pequeño. Los chunks suelen vivir en object storage como S3, GCS, Azure Blob o MinIO, mientras el índice apunta a streams definidos por combinaciones de labels. Esa decisión reduce coste, pero traslada responsabilidad al diseño de etiquetas.
La regla práctica es simple: las labels deben tener cardinalidad controlada. cluster, namespace, app, environment o service suelen funcionar bien. request_id, user_id o trace_id como label pueden destruir el modelo porque multiplican streams, empeoran la compactación y hacen crecer el índice. Para esos valores es mejor filtrar en el contenido del log o apoyarse en trazas.
Loki brilla en Kubernetes porque el modelo de labels encaja con pods, namespaces y servicios. Además, su integración con Grafana es excelente: exploración de logs, saltos desde métricas, alertas con LogQL y correlación con Tempo o Prometheus.
Su debilidad aparece cuando quieres tratar los logs como un corpus de búsqueda arbitraria. Una consulta «búscame este fragmento en todos los logs de seis meses» puede ser mucho más cara que en un sistema con índice full-text. Loki está diseñado para consultas acotadas por labels y tiempo, no para reemplazar un motor de búsqueda general.
En 2026 Loki sigue muy activo. La documentación oficial lista versiones 3.x recientes, incluida la rama 3.7, y Grafana sigue posicionándolo como un sistema de agregación de logs horizontal, altamente disponible y eficiente en costes. La adquisición de Logline por Grafana refuerza además el foco en búsquedas difíciles dentro de logs, aunque no cambia el principio central: el diseño de labels sigue siendo crítico.
Cuándo brilla Loki
Loki es la elección pragmática para equipos Kubernetes que ya viven en Grafana, necesitan retener volumen a bajo coste y consultan por servicio, namespace, cluster, entorno y ventana temporal. Es menos convincente para búsqueda full-text global o análisis forense profundo.
Quickwit: búsqueda cloud-native sobre object storage
Quickwit es una plataforma de búsqueda distribuida en Rust, pensada para cargas append-only como logs y trazas. Su tesis es atractiva: mantener búsqueda potente, pero desacoplar cómputo y almacenamiento usando object storage como capa principal.
En lugar de depender de discos locales calientes, Quickwit escribe índices y splits en almacenamiento compatible con S3, Azure Blob, Google Cloud Storage o MinIO. Los indexers procesan datos, los searchers consultan segmentos y el metastore coordina el estado. El modelo usa índices invertidos optimizados para datos inmutables y almacenamiento remoto: más cercano a OpenSearch en búsqueda que Loki, pero con economía cloud-native.
Quickwit es especialmente interesante para equipos que quieren sustituir parte de un clúster Elasticsearch/OpenSearch caro, tienen logs en S3 o pueden moverlos allí, y necesitan búsquedas textuales con mejor coste operativo. También tiene integración con Grafana y APIs compatibles parcialmente con Elasticsearch/OpenSearch, lo que facilita algunos flujos existentes.
El matiz crítico para 2026 es su estado de proyecto. Datadog adquirió Quickwit en 2024. La adquisición no significó que el repositorio open source desapareciera: el repositorio quickwit-oss/quickwit sigue público y muestra actividad reciente, incluidas etiquetas y discusiones de 2026. También el plugin de Grafana de Quickwit publica compatibilidad reciente con Grafana 12.1+ y 13. Dicho eso, el riesgo de producto es distinto al de Loki u OpenSearch: la dirección estratégica está influida por Datadog y parte del esfuerzo puede orientarse a casos internos o comerciales.
La lectura honesta es esta: Quickwit no debe descartarse por estar «muerto», porque no está archivado según las fuentes revisadas. Pero sí conviene evaluarlo con más diligencia: cadencia de releases, issues críticos, roadmap, compatibilidad real de APIs, facilidad de operación y dependencia del equipo mantenedor. Para una plataforma core de observabilidad, esa evaluación pesa tanto como el benchmark.
ClickHouse: el motor analítico de la nueva observabilidad
ClickHouse nació como base de datos analítica columnar, no como plataforma de logs. Precisamente por eso se ha vuelto relevante para observabilidad. Muchos incidentes no se resuelven buscando una cadena exacta, sino agrupando por servicio, calculando percentiles, explorando cardinalidades, cruzando logs con trazas y consultando billones de eventos por rango temporal.
El modelo de ClickHouse es columnar. Los datos se almacenan por columnas, se comprimen muy bien y se consultan con ejecución vectorizada, índices primarios ordenados, data skipping indexes y motores como MergeTree. Para observabilidad, esto permite almacenar eventos anchos y leer solo las columnas necesarias.
La contrapartida es que ClickHouse no es Elasticsearch. La búsqueda full-text existe y ha mejorado, pero el punto fuerte sigue siendo el análisis estructurado y semiestructurado. Si tus consultas son «dame todos los errores 500 por versión, región y endpoint en los últimos 15 minutos», ClickHouse encaja muy bien. Si tu consulta principal es «encuentra cualquier línea que contenga una frase rara en seis meses de texto no estructurado», probablemente quieras otro componente o una estrategia híbrida.
ClickHouse se ha movido con decisión hacia observabilidad. La adquisición de HyperDX y el lanzamiento de ClickStack cambian el posicionamiento: ya no es solo «usa ClickHouse como backend y construye tú la UI», sino una pila con OpenTelemetry, HyperDX como interfaz y ClickHouse como motor. Brilla en plataformas de alto volumen, logs estructurados, trazas, métricas derivadas y consultas agregadas de baja latencia, aunque exige entender modelado, TTLs, compresión y costes de ingestión.
Comparativa rápida
| Característica | OpenSearch | Loki | Quickwit | ClickHouse |
|---|---|---|---|---|
| Modelo principal | Búsqueda distribuida sobre Lucene | Logs por streams y labels | Búsqueda distribuida cloud-native | Base analítica columnar |
| Modelo de almacenamiento | Shards, segmentos Lucene, tiers hot/warm/cold | Chunks comprimidos + índice pequeño | Índices/splits en object storage | Columnas comprimidas en MergeTree |
| Índice | Invertido, muy completo | Labels, no contenido completo | Invertido optimizado para object storage | Índice primario, data skipping, columnas |
| Full-text search | Excelente | Limitada y dependiente de filtros | Muy buena | Buena, no su principal fortaleza |
| Coste relativo | Alto | Bajo | Bajo-medio | Bajo-medio |
| Latencia de query | Baja en índices calientes bien dimensionados | Baja si acotas por labels; peor en barridos amplios | Baja-media según caché y object storage | Muy baja en agregaciones bien modeladas |
| Escalado | Maduro, pero operativo | Horizontal y económico | Desacopla cómputo y almacenamiento | Excelente en analítica e ingestión |
| Kubernetes | Bueno | Excelente | Bueno | Bueno, mejor con ClickStack/OTel |
| Grafana | Sí | Nativo | Sí | Sí |
| Compatibilidad Elasticsearch | Alta en OpenSearch | No | Parcial | No |
| Mejor caso de uso | Búsqueda compleja y compatibilidad | Logs Kubernetes de bajo coste | Búsqueda eficiente sobre S3 | Observabilidad analítica unificada |
| Riesgo principal | Coste y complejidad | Cardinalidad de labels | Ecosistema y gobernanza tras adquisición | Modelado y curva SQL/operación |
¿Cuál elegir en 2026?
La respuesta depende menos de la moda tecnológica y más del perfil del equipo.
Si eres un equipo de plataforma con herencia Elasticsearch
OpenSearch es la opción conservadora si ya tienes automatizaciones, alertas y conocimiento operacional alrededor de Elasticsearch/OpenSearch. No migres «tal cual» esperando que el coste baje: revisa mappings, retención, ILM/ISM, shards, campos indexados y separación entre datos calientes y archivo.
Si eres un equipo Kubernetes centrado en Grafana
Loki suele ser la primera opción. Es eficiente, se integra muy bien con Grafana y reduce el coste de logs operativos. La clave es gobernar labels desde el día uno: taxonomía permitida, límites de cardinalidad y consultas por contexto antes de buscar texto.
Si buscas reducir coste frente a OpenSearch sin perder búsqueda
Quickwit merece una PoC seria cuando Loki se queda corto en búsqueda y OpenSearch resulta caro. La decisión debe incluir continuidad: actividad del repositorio, releases, clientes, soporte comunitario, integración con Grafana y posición de Datadog.
Si quieres una plataforma unificada de observabilidad
ClickHouse es probablemente la apuesta más fuerte para consolidar logs, trazas, métricas derivadas y eventos en una base analítica común. ClickStack e HyperDX reducen la necesidad de construir toda la experiencia desde cero, pero la adopción depende de madurez en SQL, modelado y operación de bases analíticas.
Si tienes requisitos de seguridad, auditoría o SIEM
OpenSearch sigue siendo más natural para investigación textual y tooling de seguridad. ClickHouse puede funcionar para analítica de seguridad a escala, pero exige modelado. Loki rara vez es la primera opción para SIEM. Quickwit puede ser interesante, con ecosistema más pequeño.
Si el presupuesto es el cuello de botella
No elijas solo por coste de almacenamiento por TB. Calcula coste total: ingestión, consultas, retención, operación, backups, upgrades, formación y tiempo de incidente. Loki y ClickHouse suelen ganar en coste bruto; Quickwit puede ser muy competitivo sobre object storage; OpenSearch puede ser razonable si se limita a datos realmente buscables y calientes.
Cómo plantear una PoC de decisión
Una prueba útil no consiste en instalar cuatro Helm charts y mirar una demo. Define preguntas reales de incidentes pasados y ejecútalas sobre datos representativos:
- Últimos 7 días de logs de producción, con cardinalidad real.
- Una ventana caliente de 2 horas con alto volumen.
- Una búsqueda textual rara sobre un periodo amplio.
- Una agregación por servicio, endpoint, versión y región.
- Un flujo de correlación desde alerta a logs y trazas.
Mide ingestión sostenida, coste de almacenamiento, latencia p50/p95, complejidad de operación y experiencia del equipo. Incluye un escenario incómodo: nodo caído, object storage lento, cardinalidad inesperada o consulta mal escrita.
Conclusión
La era en la que Elasticsearch era la única opción viable para logs terminó. En 2026 hay cuatro caminos claros.
OpenSearch es la elección madura para búsqueda full-text y compatibilidad. Loki es eficiente para logs operativos en Kubernetes. Quickwit ofrece búsqueda moderna sobre object storage, con evaluación de gobernanza obligatoria tras la adquisición por Datadog. ClickHouse se consolida como motor analítico para observabilidad unificada, especialmente con ClickStack e HyperDX.
La mejor plataforma no es la que gana todos los benchmarks. Es la que responde a tus preguntas de producción con el menor coste sostenible y la menor fricción operativa para tu equipo.
CTA: decide con datos, no con preferencias
Antes de migrar o estandarizar, ejecuta una PoC de dos semanas con datos reales, consultas reales y una estimación honesta de coste total. Debe revelar qué datos van a búsqueda, cuáles a analítica y cuáles a almacenamiento barato.
Fuentes
- OpenSearch 3.0: https://opensearch.org/blog/unveiling-opensearch-3-0/
- OpenSearch 3.0, Lucene 10 y JVM 21: https://opensearch.org/blog/opensearch-3-0-what-to-expect/
- Grafana Loki, documentación: https://grafana.com/docs/loki/latest/
- Grafana Loki, releases 3.x: https://grafana.com/docs/loki/latest/release-notes/
- Grafana Loki, labels y cardinalidad: https://grafana.com/blog/how-labels-in-loki-can-make-log-queries-faster-and-easier/
- Datadog adquiere Quickwit: https://www.datadoghq.com/blog/datadog-acquires-quickwit/
- Quickwit OSS: https://github.com/quickwit-oss/quickwit
- Quickwit datasource para Grafana: https://github.com/quickwit-oss/quickwit-datasource
- ClickStack: https://clickhouse.com/clickstack
- ClickStack/HyperDX en ClickHouse Cloud: https://clickhouse.com/docs/use-cases/observability/clickstack/overview
- ClickHouse adquiere HyperDX: https://clickhouse.com/blog/202504-newsletter
- ClickHouse y observabilidad 2026: https://clickhouse.com/resources/engineering/what-is-observability