DuckDB, ClickHouse, Druid o Pinot: cómo elegir motor OLAP

DuckDB, ClickHouse, Druid y Pinot resuelven problemas distintos. Árbol de decisión y tabla comparativa para elegir el motor OLAP correcto según tu caso de uso.

Tabla de Contenidos

No es un ranking, es un árbol de decisión
La tabla comparativa
DuckDB: cuando no necesitas un servicio
ClickHouse: el punto de equilibrio para producción
Druid y Pinot: cuando sí necesitas tiempo real a escala masiva
Casos reales mapeados
Preguntas frecuentes
Conclusión

No es un ranking, es un árbol de decisión

La razón por la que las comparativas genéricas de "DuckDB vs ClickHouse vs Druid vs Pinot" suelen confundir más de lo que aclaran es que mezclan dos preguntas distintas como si fueran una sola:

Pregunta 1: ¿necesitas un servicio, o te basta con una librería? DuckDB corre dentro de tu proceso. Los otros tres son servicios que levantas aparte, con puertos, usuarios y alta disponibilidad de por medio.

Pregunta 2: si necesitas un servicio, ¿cuál es tu prioridad, la analítica de propósito general o la latencia bajo concurrencia extrema? ClickHouse está optimizado para lo primero. Druid y Pinot nacieron para lo segundo.

Con esas dos preguntas respondidas, el árbol queda así:

¿Tus consultas las lanza un único proceso —tu backend, un notebook, un script de ETL— y los datos caben cómodamente en un disco? → DuckDB. No necesitas nada más.
¿Necesitas un servicio compartido, con escrituras continuas desde varias fuentes, y tu carga es "agregaciones sobre una tabla de eventos que crece"? → ClickHouse. Es el punto de equilibrio para la inmensa mayoría de proyectos, desde un maker solo hasta un equipo mediano.
¿Tu prioridad no es la analítica exploratoria sino servir la misma consulta pre-definida a miles de usuarios simultáneos con latencia de milisegundos, alimentada por streaming desde Kafka? → Druid o Pinot. Y solo si tienes gente dedicada a operarlos.

El error que más veces he visto es saltarse el paso 1 por instinto —"vamos a montar algo serio"— cuando el 80% del volumen real cabía en una máquina. Y el segundo error, menos frecuente pero más caro, es llegar al paso 3 sin tener la carga que lo justifica: acabas operando un cluster de seis procesos para un problema que ClickHouse resolvía con un binario.

La tabla comparativa

	DuckDB	ClickHouse	Apache Druid	Apache Pinot
Arquitectura	Embebida, in-process, sin servidor	Columnar distribuida, un binario por nodo	Columnar distribuida, procesos especializados	Columnar distribuida, procesos especializados
Despliegue mínimo	Una librería (`pip install duckdb`)	1 binario	6 tipos de proceso + ZooKeeper + metadata store	Controller, Broker, Server + ZooKeeper
Mejor caso de uso	Análisis local, notebooks, ETL, backend de una app que consulta sus propios archivos Parquet/CSV	Tabla de eventos en producción con agregaciones frecuentes, self-hosted	Ingesta streaming con exploración ad-hoc y tiering de datos calientes/fríos	Servir la misma consulta pre-definida a concurrencia masiva con SLA de milisegundos
Complejidad operativa	Nula: no hay nada que operar	Baja–media: un servicio más que mantener	Alta: requiere equipo dedicado	Alta: requiere equipo dedicado
Ingesta streaming	No aplica	Buena (Kafka engine, vistas materializadas)	Excelente, su razón de ser	Excelente, su razón de ser
Concurrencia	Baja (un proceso)	Muy buena	Buena	Excelente, diseñada para esto
Consultas ad-hoc flexibles	Excelente	Excelente	Buena	Limitada: brilla con patrones conocidos de antemano
Cuándo NO usarlo	Necesitas que varios lectores/escritores compartan los datos en vivo, o escalar más allá de una máquina	Necesitas latencia sub-segundo garantizada a decenas de miles de QPS concurrentes	Eres un equipo pequeño sin SRE dedicados, o tu prioridad es exploración libre sin patrones fijos	Eres un equipo pequeño sin SRE dedicados, o tus consultas cambian constantemente de forma

Las celdas son simplificaciones; el detalle está en las secciones siguientes.

DuckDB: cuando no necesitas un servicio

DuckDB lo crearon Mark Raasveldt y Hannes Mühleisen en el CWI (Centrum Wiskunde & Informatica) de Ámsterdam, con la primera versión pública anunciada en 2019 en la conferencia SIGMOD. La motivación de origen es reveladora: venían de intentar embeber MonetDB en paquetes de R y Python, y descubrieron que ninguna base de datos analítica existente estaba diseñada para vivir dentro de otro proceso sin asumir que ella mandaba. DuckDB nació para llenar exactamente ese hueco.

Es, en la práctica, lo que SQLite es para OLTP pero para analítica: una librería, no un servicio. pip install duckdb y ya tienes un motor columnar vectorizado corriendo dentro de tu script, con dialecto SQL compatible con PostgreSQL. Consulta Parquet y CSV directamente desde disco o desde una URL, se integra de forma nativa con pandas y Polars, y no hay puerto que abrir ni proceso que supervisar.

Dónde gana: cualquier flujo donde una sola persona o un solo proceso hace las consultas. Ciencia de datos exploratoria, notebooks, el backend analítico de una app pequeña que solo necesita leer sus propios datos, pipelines de ETL que transforman archivos. Para ese perfil de carga, es difícil encontrarle un rival serio en simplicidad.

Dónde pierde, y por qué no es un defecto sino un diseño: DuckDB es fundamentalmente un solo proceso. No sirve datos a docenas de lectores concurrentes desde distintas máquinas, no escala horizontalmente, y no está pensado para recibir escrituras constantes desde múltiples fuentes a la vez. Existe MotherDuck como capa cloud para quien necesita compartirlo, pero en ese momento ya has cambiado de categoría de herramienta.

La señal de que ya no te sirve: cuando necesitas que varios servicios escriban a la vez y varios clientes lean a la vez, sin que unos bloqueen a otros. Ahí cruzas a ClickHouse.

ClickHouse: el punto de equilibrio para producción

Si DuckDB resuelve "un proceso, mis datos", ClickHouse resuelve "un servicio, los datos de todos". Es la opción cuando necesitas que la analítica deje de ser un script que corres tú y se convierta en algo que recibe escrituras 24/7 desde tu aplicación y responde consultas de tu equipo o de tus clientes.

No voy a repetir aquí toda su arquitectura columnar y sus índices dispersos —lo cubro con detalle en qué es ClickHouse y cómo instalarlo—, pero el resumen para esta decisión es: un binario, sin JVM, sin ZooKeeper obligatorio, que escala desde un portátil hasta cientos de nodos con el mismo motor.

Dónde gana frente a Druid y Pinot: todo lo que no sea el caso extremo de concurrencia masiva con SLA de milisegundos. Consultas ad-hoc exploratorias, JOINs razonables, un equipo pequeño que no tiene SRE dedicados, coste operativo bajo. La inmensa mayoría de "necesito tiempo real" en realidad significa "necesito que el dato esté disponible en segundos, no en minutos", y ahí ClickHouse sobra de sobra.

Dónde pierde frente a Druid y Pinot: si tu SLA real es de milisegundos con decenas de miles de consultas concurrentes idénticas —piensa en un feature de producto que consultan simultáneamente cientos de miles de usuarios finales—, ClickHouse puede quedarse corto sin un esfuerzo de tuning considerable, mientras que Druid y Pinot están diseñados desde cero para exactamente ese perfil.

Cuándo NO usar ClickHouse en este contexto: si tus datos caben en una máquina y los consulta un solo proceso, es sobre-ingeniería frente a DuckDB. Si tu SLA es de milisegundos a concurrencia extrema con streaming desde Kafka, es la herramienta equivocada frente a Druid o Pinot.

Druid y Pinot: cuando sí necesitas tiempo real a escala masiva

Druid y Pinot comparten familia: ambos corren sobre la JVM, ambos separan el sistema en varios tipos de proceso especializados, ambos dependen de ZooKeeper para coordinación, y ambos esperan una tubería de ingesta tipo Kafka alimentándolos en continuo. Ambos son, también, notablemente más complejos de operar que ClickHouse: no es una opinión, es una consecuencia directa de tener seis (Druid) o tres (Pinot) tipos de proceso distintos que desplegar, monitorizar y escalar por separado, en vez de un binario.

Pero no son intercambiables entre sí, porque nacieron para resolver problemas distintos.

Apache Druid: de la analítica de ad-tech al streaming general

Druid nació en 2011 dentro de Metamarkets, una empresa de publicidad programática que necesitaba analizar miles de millones de eventos con drill-down y roll-up en tiempo real y descubrió que ni MySQL ni HBase daban la velocidad necesaria. Se abrió como open source en 2012 y pasó a licencia Apache en 2015.

Ese origen —analítica exploratoria sobre streams de eventos, con dimensiones que cambian y usuarios que quieren cortar los datos de formas no previstas— sigue marcando su diseño. Druid separa explícitamente los datos "calientes" (recientes, en memoria) de los "fríos" (históricos, en almacenamiento profundo), y eso lo hace fuerte quien necesita retención larga con consultas exploratorias sobre el histórico completo, no solo sobre lo último.

Dónde gana frente a Pinot: flexibilidad para consultas ad-hoc no anticipadas y gestión de datos por antigüedad. Si tu equipo de analistas quiere poder preguntar cosas nuevas sobre el histórico sin rediseñar índices, Druid da más margen.

Apache Pinot: nacido para servir, no para explorar

Pinot nació en LinkedIn con un objetivo mucho más estrecho y específico: servir funcionalidades como "quién ha visto tu perfil" a cientos de millones de usuarios con latencia de milisegundos. No es casualidad que su arquitectura —índices en estrella, índices invertidos, particionamiento pensado para patrones de acceso conocidos— esté optimizada para ejecutar la misma forma de consulta una y otra vez, muy rápido, para mucha gente a la vez.

Dónde gana frente a Druid: concurrencia bruta en consultas predefinidas. Si sabes de antemano la forma de las consultas que vas a servir —un dashboard de producto con filtros fijos, un contador de métricas por usuario— y tu prioridad es aguantar decenas de miles de consultas simultáneas con latencia mínima, Pinot está más afinado para exactamente eso.

Dónde pierde frente a Druid: consultas exploratorias con formas nuevas. Pinot brilla cuando conoces tus patrones de acceso e indexas para ellos; incomoda cuando alguien quiere preguntar algo que nadie anticipó.

La regla práctica Druid vs. Pinot

Si tu problema es "analítica en tiempo real de cara a un equipo interno que explora libremente", inclínate por Druid. Si tu problema es "analítica en tiempo real de cara al usuario final, con consultas predecibles y concurrencia masiva", inclínate por Pinot. Y si no tienes claro cuál de los dos escenarios describe tu caso, es una señal bastante fuerte de que todavía no necesitas ninguno de los dos: probablemente tu problema real es el paso 2 del árbol, no el paso 3.

Cuándo NO usar ninguno de los dos: si tu equipo son pocas personas sin experiencia operando sistemas distribuidos sobre JVM, el coste de mantener seis procesos coordinados por ZooKeeper no se amortiza salvo a escalas muy grandes. Es sintomático que varias empresas conocidas hayan migrado cargas de Druid a ClickHouse citando reducción de coste y simplicidad, precisamente porque su volumen real no exigía la complejidad que estaban pagando.

Casos reales mapeados

Para bajar esto de la teoría, cuatro escenarios concretos y a qué herramienta apuntan:

Analista de datos explorando ventas históricas en Parquet desde un notebook. DuckDB. Sin discusión: un proceso, datos que caben en el portátil, cero necesidad de compartir estado con nadie.

SaaS B2B con una tabla de eventos de producto que crece cada día y un dashboard interno que varias personas consultan. ClickHouse. Servicio compartido, escrituras continuas, concurrencia moderada, sin necesidad de latencia de milisegundos garantizada.

Plataforma de ad-tech que ingiere impresiones desde Kafka y necesita que su equipo de analistas corte esos datos por dimensiones arbitrarias en tiempo casi real, con retención de meses. Druid. Ingesta streaming, exploración flexible, tiering caliente/frío.

Red social o producto de consumo masivo que muestra una métrica personalizada —"tus estadísticas de esta semana"— a millones de usuarios simultáneos con un SLA de latencia estricto. Pinot. Consulta predefinida, concurrencia extrema, patrón de acceso conocido de antemano.

Si tu escenario no encaja claramente en ninguno de los cuatro, vuelve al árbol de decisión del principio: casi siempre la respuesta correcta es la opción más simple que resuelve el problema de hoy, no la más impresionante.

Preguntas frecuentes

¿DuckDB o ClickHouse?

DuckDB si un solo proceso hace las consultas y tus datos caben en una máquina: notebooks, ETL, backend de una app pequeña. ClickHouse cuando necesitas un servicio compartido con escrituras continuas desde varias fuentes y varios lectores concurrentes. La frontera es "librería" vs. "servicio", no rendimiento.

¿ClickHouse o Druid, cuál elegir?

ClickHouse para la inmensa mayoría de casos: menor complejidad operativa, un binario frente a seis tipos de proceso, y rendimiento sobrado para analítica de propósito general. Druid solo si tu carga real es ingesta streaming masiva con exploración ad-hoc sobre datos calientes y fríos, y tienes equipo dedicado a operarlo.

Apache Pinot vs. Druid vs. ClickHouse, ¿cuál es mejor?

No hay un "mejor" universal. ClickHouse para analítica general en producción con complejidad operativa baja. Druid para streaming con exploración flexible y gestión de datos por antigüedad. Pinot para servir consultas predefinidas a concurrencia masiva con latencia de milisegundos. Elige por tu patrón de carga, no por benchmark.

¿ClickHouse o Vertica?

Son categorías distintas más de lo que parece. Vertica es un MPP columnar propietario (con una edición community limitada) pensado para grandes empresas con presupuesto de licencia y equipo de DBA. ClickHouse es open source sin coste de licencia, se despliega como un binario y encaja mucho mejor con un equipo pequeño que quiere self-hosting sin negociar un contrato.

¿Puedo migrar de Druid o Pinot a ClickHouse más adelante, o al revés?

Sí, en ambas direcciones, aunque no es trivial: los modelos de ingesta y las consultas más idiomáticas de cada uno no son un calco directo. Lo habitual es empezar por ClickHouse por su menor coste operativo y migrar a Druid o Pinot solo si la concurrencia o el SLA real lo exigen de forma medible, no anticipada.

Conclusión

Las cuatro herramientas de este post son excelentes en lo suyo, y esa es precisamente la razón de que la pregunta "¿cuál es mejor?" esté mal planteada. DuckDB gana cuando el trabajo lo hace un proceso. ClickHouse gana cuando necesitas un servicio de propósito general con complejidad operativa razonable. Druid y Pinot ganan solo en el extremo de streaming masivo con SLA de milisegundos, y solo si tienes quien los opere.

Para la mayoría de proyectos que arrancan hoy, el camino natural es empezar por DuckDB mientras los datos caben en una máquina, y dar el salto a ClickHouse cuando necesites que ese análisis se convierta en un servicio compartido. Si llegas de verdad al escalón de Druid o Pinot, lo sabrás porque el dolor será concreto y medible, no una intuición de que "esto tiene que ser más grande de lo que es".

Si ClickHouse es tu siguiente paso, el camino más corto es qué es ClickHouse y cómo instalarlo, y si quieres ver el resto de opciones del mercado con más detalle, la comparativa de alternativas a ClickHouse entra en StarRocks, TimescaleDB y los warehouses cloud que este post deja fuera a propósito por no encajar en el árbol de decisión de motores en tiempo real.