Las mejores bases de datos columnares para analítica en tiempo real

ClickHouse se lleva el primer puesto por una velocidad que se siente, y nuestra primera consulta sobre la tabla cargada de mil millones de filas volvió antes de que termináramos de leer el panel de salida. Una agregación filtrada sobre una ventana móvil de siete días regresó en pocos cientos de milisegundos en frío, y se mantuvo por debajo del segundo cuando empujamos el panel a mil usuarios concurrentes. Esa combinación de motor de ejecución vectorizado y compresión columnar agresiva es toda la propuesta, y en escaneos analíticos brutos nada más de esta lista lo igualó. Cuando incluso dos segundos de latencia arruinarían una función orientada al cliente, este es el motor que te compra el margen.

La compresión es el segundo acto silencioso. Nuestra tabla de eventos ancha y desnormalizada aterrizó en disco a una fracción del tamaño que reportaron los almacenes en la nube para los mismos datos, y eso importa dos veces: leer menos significa escanear más rápido, y guardar menos significa una factura menor. Vimos el mismo conjunto encogerse con fuerza mientras ClickHouse aplicaba códecs por columna, y el motor luego solo tocaba el puñado de columnas que cada agregación necesitaba de verdad.

Nada de esta velocidad viene sin filos, y el dialecto SQL es el primero con el que chocas. Las funciones tienen nombres propios de ClickHouse, el sistema de tipos es más estricto que la media, y un ingeniero que llega de Postgres pasará la primera semana peleando con una sintaxis que parece casi, pero no del todo, familiar. Una vez aprendidos los patrones la productividad vuelve, aunque la rampa es real y conviene presupuestarla.

La limitación estructural son los joins, y no es sutil. ClickHouse está hecho para volar sobre una tabla ancha y completamente desnormalizada, y en cuanto introdujimos un modelo normalizado de hechos y dimensiones con un join real de varias tablas, la elegancia se evaporó y el rendimiento cayó en picado. Mutar datos es el otro punto blando: actualizaciones y borrados disparan reescrituras pesadas que lo convierten en mal encaje para cualquier cosa parecida a la rotación transaccional. La recomendación aguanta igual. Para un equipo técnico que construye analítica en tiempo real orientada al usuario sobre datos de eventos append-only, ClickHouse es el motor más rápido de aquí y el que hay que superar.

Donde ClickHouse gana en velocidad de escaneo bruta, Apache Pinot gana la prueba que más importa para una función de producto en vivo: la concurrencia. Empujamos el mismo panel de diez usuarios a mil, y donde varios motores de tipo almacén empezaron a trepar pronto, Pinot mantuvo una línea de latencia casi plana en las decenas de milisegundos durante todo el ascenso. Este es el motor que LinkedIn construyó para servir analítica dentro de su propio producto a cientos de miles de consultas por segundo, y esa herencia se nota en cuanto llega la multitud. Si ClickHouse es el velocista, Pinot es el motor que pones detrás de una función que miles de usuarios finales consultan en el mismo segundo.

El mecanismo detrás de la línea plana es el indexado, y Pinot te da más que ningún otro de aquí. Su índice star-tree prematerializa agregaciones a lo largo de combinaciones de dimensiones, así que un conteo filtrado que de otro modo escanearía un segmento se resuelve contra un árbol precalculado. Añadimos un índice star-tree a nuestra tabla de panel de alta cardinalidad y vimos caer notablemente la latencia de cola bajo carga. Los índices invertido, de rango y JSON cubren las demás formas de consulta, y la recompensa es real cuando conoces tus consultas de antemano.

Ese requisito de conocimiento es la contrapartida. Pinot premia las tablas diseñadas en torno a las consultas que servirán, y castiga la improvisación. Cuando lanzamos una consulta exploratoria imprevista contra una tabla afinada para otro patrón, la respuesta fue del montón en lugar de excepcional. Este no es el motor para un analista rebuscando entre datos sin patrón de acceso fijo; un almacén generalista encaja mejor ahí.

Llegar hasta aquí es trabajo. Levantar un clúster de Pinot implica correr controllers, brokers y servers, luego escribir configs de tabla y esquema y elegir índices con criterio, y la curva es más empinada que la de los almacenes en la nube del final de esta lista. Los joins son el límite funcional: el soporte ha mejorado pero sigue por detrás de un motor SQL generalista, así que las tablas preagregadas o desnormalizadas siguen siendo el camino rápido. Para un equipo que incrusta analítica directamente en un producto con concurrencia seria, nada de eso cambia el veredicto. Es el mejor motor en tiempo real orientado al usuario de la lista.

Cuando abrimos un flujo de Kafka en vivo de telemetría simulada y observamos la consola de Druid, un evento recién publicado se volvió consultable en pocos segundos, indexado y agregado sin un paso por lotes a la vista. Ese único instante es toda la razón por la que Druid existe. Ingiere un flujo, columnariza e indexa con bitmap cada fila según llega, y la archiva en un segmento particionado por tiempo, de modo que un panel operativo filtrando por muchas dimensiones de alta cardinalidad sigue rápido sobre datos que todavía están llegando. Para trabajo de clickstream y telemetría donde la frescura es el objetivo, este comportamiento es justo lo que quieres.

La alta cardinalidad es donde Druid se separa. Cargamos una dimensión con millones de valores distintos, de las que convierten un índice ingenuo en peso muerto, y las columnas de Druid, codificadas por diccionario e indexadas con bitmap, mantuvieron ágiles las agregaciones filtradas. El diseño de segmentos por tiempo compone el beneficio: una consulta acotada a la ultima hora solo toca los segmentos que cubren esa hora, así que los paneles por rango temporal siguen baratos según crece el historial. Gestionar la retención se vuelve cuestión de descartar segmentos viejos en lugar de borrar filas.

El coste de todo esto es operativo, y es empinado. Druid no es un proceso sino una familia de ellos: coordinators, overlords, brokers, historicals y middle managers, cada uno con su tarea y cada uno pidiendo ser dimensionado y mantenido con vida. Levantar un clúster y afinarlo le llevó a nuestro equipo más que cualquier otro motor de aquí, y correrlo en producción es un compromiso real, no una tarde.

Los joins son la otra debilidad histórica. Druid se construyó para agregaciones sobre datos de eventos, no para SQL de varias tablas, y aunque la capa SQL reciente ha mejorado el asunto, un join pesado en estrella encaja mejor en un almacén generalista o en StarRocks. Actualizaciones y borrados siguen siendo incómodos sobre un almacenamiento fundamentalmente append-oriented. Para un equipo que corre analítica operativa en tiempo real sobre flujos de eventos de alta cardinalidad, sin embargo, Druid se gana su sitio: pocos motores mantienen datos frescos de dimensiones anchas tan consultables y tan rápido.

La queja con la que chocábamos una y otra vez con ClickHouse, Pinot y Druid eran los joins, y StarRocks es el motor que la responde. Donde esos tres alcanzan su velocidad asumiendo una tabla ancha y plana, StarRocks se construyó desde cero con un motor MPP vectorizado y un optimizador de costes que manejan un join real en estrella a velocidad. Cambiamos nuestra tabla de eventos plana por un modelo normalizado de hechos y dimensiones, corrimos la misma agregación, y StarRocks mantuvo su latencia donde los motores optimizados para tablas planas cayeron en picado. Esa es la diferencia entre un almacén OLAP y algo a lo que puedes apuntar BI directamente.

El segundo diferenciador es dónde pueden vivir los datos. StarRocks consulta formatos de tabla abiertos como Iceberg y Hudi directamente, así que un equipo de datos puede acelerar BI contra un lakehouse sin copiar nada a un almacén aparte primero. Lo apuntamos a una tabla Iceberg y corrimos consultas multidimensionales con joins sin migración alguna, y sus vistas materializadas mantenidas automáticamente aceleraron en silencio las que repetíamos. Para equipos comprometidos con un lakehouse abierto, esto elimina un pipeline entero de copia y sincronización.

La compatibilidad con el protocolo MySQL es el detalle pragmático que hace la adopción más fácil que la de sus rivales. Nuestro cliente de BI existente conectó como si StarRocks fuera un servidor MySQL, sin driver especial, lo que acorta bastante el camino de la instalación al primer panel.

Las contrapartidas son honestas. Esto sigue siendo un clúster MPP, y operarlo y afinarlo exige la misma clase de habilidad operativa que piden Pinot y Druid, aunque el premio sea mayor flexibilidad de consulta. El ecosistema es más joven que el de Redshift o BigQuery, así que de vez en cuando serás el primero en topar con cierto borde de integración. Las cargas de upsert en tiempo real, en particular, necesitan el modelo de tabla adecuado elegido de antemano para rendir. Para un equipo de lakehouse o de BI que necesita velocidad columnar y joins reales sobre formatos de tabla abiertos, StarRocks es el destacado de esta lista.

Imagina al equipo que ama la arquitectura de Snowflake pero no puede publicar un panel en vivo orientado al cliente sobre él porque las consultas son demasiado lentas. Ese es exactamente el destinatario de Firebolt, y en las pruebas cumplió. El motor que alimenta la pestaña Campaign Analytics de una plataforma de MarTech, donde diez mil marketers esperan gráficos en vivo en menos de medio segundo, está haciendo justo el trabajo que le pedimos: analítica de aplicaciones por debajo del segundo a escala.

El mecanismo es el indexado disperso, y es genuinamente distinto del escaneo por fuerza bruta en el que se apoyan casi todos los motores. En vez de leer una tabla y filtrar, Firebolt usa su índice para ignorar matemáticamente los terabytes que no pueden coincidir con una consulta, y luego lee solo el rango relevante. Corrimos una consulta filtrada contra una tabla grande y Firebolt la devolvió en la banda de sub-segundo de forma consistente, y lo hizo sin aprovisionar el cómputo sobredimensionado que un almacén necesitaría para clavar el mismo número. Esa eficiencia apareció directamente como una factura de AWS más baja durante la prueba.

Para un ingeniero de datos que construye aplicaciones la ergonomía encaja con la misión. La granularidad de cómputo permite tallar un motor pequeño y rápido dedicado a una función sensible a la latencia en lugar de compartir un almacén monolítico, y la sintaxis compatible con PostgreSQL significa que el SQL que tu equipo ya escribe funciona casi tal cual. Los equipos que migraron una función en vivo fuera de Snowflake encontraron la transición más corta de lo esperado.

Las limitaciones son las que cabría esperar de un producto enfocado y más joven. El ecosistema de integraciones no se acerca a la red de miles de proveedores de Snowflake, así que un conector de nicho puede no existir aun. Actualizaciones y borrados pueden desencadenar un reindexado pesado, lo que hace de Firebolt un mal hogar para datos que mutan. Y no se posiciona como tu único almacén para todo; se sienta junto a un data lake, haciendo el trabajo rápido de cara a la aplicación y dejando el reporte por lotes general en otra parte. Para analítica por debajo del segundo dentro de un producto en vivo sobre AWS, es una opción sólida y construida a propósito.

La capacidad estelar de SingleStore es que borra el paso de copia sobre el que se construyen casi todas las pilas de tiempo real. Su formato Universal Storage mezcla la velocidad de escaneo del columnstore con el rendimiento de búsqueda y actualización del rowstore en una sola tabla, de modo que un único motor sirve tanto una búsqueda puntual como una agregación analítica. Escribimos registros por la vía transaccional y los consultamos analíticamente milisegundos después, sobre los mismos datos, sin un pipeline de ingesta trasegando filas a un almacén analítico aparte. Para una aplicación que necesita paneles en vivo sobre datos según se escriben, esa arquitectura elimina una pieza móvil entera.

Este diseño HTAP es el diferenciador de verdad frente a todo lo demás de la lista. Los otros motores de aquí asumen una separación entre dónde se escriben los datos y dónde se analizan, y optimizan el lado de lectura. SingleStore corre la escritura transaccional y la consulta analítica en un solo sistema, y su ejecución vectorizada combinada con la ingesta sin bloqueos mantuvo la latencia baja incluso mientras las mismas tablas absorbían un flujo constante de escrituras. La analítica operativa sobre datos genuinamente vivos es el caso de uso que domina.

La amplitud de esa capacidad es también su coste. Soportar bien ambas cargas implica un conjunto de funciones ancho, y la superficie de configuración es mayor que la de un almacén de propósito único: tipos de tabla, modelos de almacenamiento y claves de shard importan y hay que decidirlos con criterio. Elegir mal la clave de shard al principio nos dejó rendimiento sobre la mesa hasta que lo corregimos.

El precio es la otra consideración. Para analítica pura sin requisito transaccional ni de tiempo real, un almacén dedicado suele ser más barato y sencillo, y la versatilidad de SingleStore es presupuesto desperdiciado en ese caso. Su valor aparece justo cuando de otro modo estarías operando y sincronizando dos bases de datos. Para equipos que construyen aplicaciones operativas en tiempo real que necesitan analítica sobre datos recién escritos, es el encaje más limpio de aquí.

Empieza por la limitación honesta, porque decide dónde encaja Redshift en una lista de tiempo real. Bajo nuestra prueba de concurrencia, Redshift no mantuvo la línea de latencia plana que sí sostuvieron Pinot y Druid; los tiempos de respuesta treparon antes según crecía la multitud simulada, y necesitó el escalado de concurrencia para aguantar en lugar de absorber la carga de forma nativa. Esto es un almacén primero y un motor de tiempo real después, y fingir lo contrario prepara a un equipo para la decepción. Si tu listón son mil usuarios concurrentes machacando una función en vivo, los motores de arriba se construyeron para eso y Redshift no.

Lo que Redshift sí hace, lo hace de maravilla. Para un equipo que ya vive dentro de AWS, corriendo miles de consultas densas y optimizadas cada hora contra cargas predecibles, la economía es difícil de rebatir. El precio por nodo reservado a escala dejó atrás a los motores de pago por consulta en nuestra comparación de coste, y la integración es donde se gana el sueldo: consultar S3 con Spectrum, hacer streaming desde Kinesis y alimentar SageMaker ocurre todo dentro de la red de AWS sin cargos de egress ni fontanería externa. Los datos que ya viven en S3 y se mueven por Glue nunca tienen que salir de casa.

El control es una fortaleza genuina para el equipo adecuado. A diferencia de un almacén automatizado de caja negra, Redshift expone claves de ordenación, estilos de distribución y vacuuming, y un equipo que invierte en afinar puede exprimir un rendimiento que un motor sin manos no te dará. Ese mismo control es un coste: requiere conocimiento activo de DBA para montarlo bien, y sin afinar un clúster desarrolla cuellos de botella. La opción Serverless suaviza esto para equipos que prefieren no gestionar nodos, y ha cerrado buena parte de la brecha de facilidad de uso. Compartir datos entre organizaciones sigue siendo más torpe que en Snowflake. Para cargas analíticas predecibles y residentes en AWS, Redshift es el estándar rentable.

Escribimos una consulta contra una tabla de varios terabytes y pulsamos ejecutar, y BigQuery respondió sin que nuestro equipo aprovisionara un solo nodo. Esa es toda la experiencia, y es lo que lo pone en esta lista. Detrás del prompt de SQL, Google levanta miles de trabajadores invisibles, ejecuta el escaneo y los desmonta, así que una búsqueda ad-hoc sobre miles de millones de filas de clickstream termina en segundos sin infraestructura en la que pensar. Para un equipo que quiere cero gestión de clúster y consultas ocasionales a escala planetaria, nada de aquí es más simple.

El modelo serverless es una liberación genuina para el trabajo exploratorio. Un científico de datos puede interrogar un registro de eventos de cinco años a voluntad sin pedirle a nadie que dimensione una máquina mayor, y BQML extiende ese alcance al dejar que el mismo analista entrene y ejecute modelos predictivos directamente en SQL, dentro del almacén, sin una pila de ML aparte. Durante las pruebas la elasticidad nunca parpadeó, escalando de una consulta filtrada pequeña a una agregación de tabla completa sin cambio de configuración.

El modelo de facturación es donde las ambiciones de tiempo real chocan con la realidad, y hay que decirlo sin rodeos. BigQuery cobra por byte escaneado, lo cual es elegante para consultas grandes infrecuentes y peligroso para un panel en vivo. Una vista de Tableau mal optimizada refrescando cada pocos minutos contra una tabla grande puede producir una factura genuinamente alarmante, y vimos moverse los costes rápido cuando una consulta tocaba más datos de los necesarios. Las cuotas y el diseño cuidadoso de consultas no son opcionales aquí; son la diferencia entre gasto predecible y un incidente de finanzas.

Los otros filos son menores en comparación: el SQL estándar tiene rarezas que pillan a ingenieros llegados de otros almacenes, y el aislamiento de cómputo es menos granular de lo que querrían los equipos que buscan facturación estricta por departamento. Para escalado analítico serverless y sin operaciones sobre cargas exploratorias o a ráfagas, especialmente dentro del ecosistema de Google, BigQuery es la opción sin esfuerzo. Solo mantenlo lejos de un panel en vivo de alta frecuencia salvo que tengas los controles de coste bien atados.

Si tu empresa mide sus datos en gigabytes o unos pocos terabytes y alguien insiste en que necesitas un clúster del tamaño de Snowflake para analizarlos, MotherDuck es el argumento en contra. Se apoya en DuckDB, el motor analítico local que corre dentro de un solo proceso, y lo extiende a una nube serverless colaborativa. Consultamos un fichero Parquet de cincuenta gigabytes directamente desde un portátil y obtuvimos resultados en milisegundos sin levantar nada, que es la experiencia de desarrollo que la comunidad de DuckDB alaba con razón.

La parte ingeniosa es la ejecución híbrida, y encaja con esta audiencia ligera con precisión. Una consulta puede correr en parte en la RAM local y en parte en la nube, así que un join entre un fichero Parquet de tu máquina y una tabla mayor alojada en MotherDuck se resuelve sin arrastrar todo el conjunto de la nube hasta el portátil. Para un equipo de datos esbelto, eso significa la ergonomía del DuckDB local con un almacén compartido en la nube atornillado, y nada del aprovisionamiento de clúster que define a los almacenes de arriba. La diferencia de coste es real: para cargas de un solo dígito de terabytes esto dejó atrás a los grandes almacenes por un amplio margen en nuestra comparación.

Las limitaciones son exactamente lo que esperarías de un producto joven y deliberadamente acotado. La gobernanza empresarial, el control de acceso fino y las funciones de cumplimiento todavía se están construyendo, así que una empresa regulada encontrará huecos que un almacén maduro cubrió hace años. Las integraciones con BI legado on-premise son escasas.

Y el posicionamiento es honesto sobre su techo: si de verdad guardas cincuenta petabytes de datos crudos y no estructurados en streaming, necesitas el peso distribuido de BigQuery, no esto. MotherDuck no intenta ser ese motor, y tratarlo como tal sería un error. Para equipos pragmáticos en el rango de gigabytes a terabytes que quieren analítica rápida, coste bajo y un dialecto de SQL que sus ingenieros ya disfrutan, cierra esta lista como una opción de veras refrescante.