# Bases de datos OLAP open source > Empieza por las consultas y el objetivo de frescura. Consultar Parquet en un portátil y servir dashboards concurrentes a clientes son cargas analíticas. Justifican arquitecturas distintas. Compararía forma de las consultas, actualizaciones, retraso de ingesta y recuperación antes de comparar cifras de rendimiento. 1. 01 **Ingesta y lotes** Streams, logs CDC o archivos en almacenamiento de objetos entran en lotes acotados para no saturar merges ni creación de segmentos. 2. 02 **Diseño columnar e índices** Los datos se ordenan, comprimen y particionan en partes columnares, segmentos o Parquet externos con mapas de zona e índices de salto. 3. 03 **Ejecución vectorizada** Motores en proceso o coordinadores MPP podan particiones, empujan filtros y ejecutan escaneos vectorizados, agregaciones y joins. 4. 04 **Concurrencia y recuperación** Vistas materializadas, réplicas, snapshots y almacenamiento profundo fijan cuántos lectores simultáneos atiende el sistema y cómo se recupera. Recorrido analítico desde la ingesta hasta la consulta. Motores embebidos, SQL federado y almacenes columnares distribuidos priorizan etapas distintas. ## Comparación de un vistazo **Fuentes revisadas: octubre de 2026**, a partir de repositorios, versiones y documentación oficiales. La tabla combina servidores distribuidos, un motor embebido y una extensión PostgreSQL. Cada calificación (1–5) es una nota editorial de preparación para el encaje de su fila; el desglose está bajo la tabla y el [método](), en el índice del Blog. | Proyecto | Calificación | Licencia del núcleo | Lo preseleccionaría para | Restricción principal | | :--- | :--- | :--- | :--- | :--- | | [DuckDB 1.5.6]() | 5/5 | MIT | Analítica embebida, exploración de Parquet y procesos batch acotados | La base nativa dentro del proceso tiene un único proceso escritor; un servicio compartido requiere otro diseño. | | [ClickHouse 26.8.27.9 LTS]() | 4,5/5 | Apache-2.0 | SQL columnar sobre eventos y datasets analíticos | Diseño de tablas, lotes de ingesta, merges y replicación necesitan decisiones explícitas. | | [Apache Doris 4.1.4.1]() | 4,5/5 | Apache-2.0; excepciones en dependencias | Analítica SQL compartida, reporting y consultas al lake | Hay que operar metadatos frontend y datos backend; el despliegue cambia los componentes. | | [StarRocks 4.1.6]() | 4,5/5 | Apache-2.0 | BI, joins, vistas materializadas y analítica del lake | Topología de almacenamiento y cómputo y actualización de vistas forman parte del diseño. | | [Trino 483]() | 4,5/5 | Apache-2.0 | SQL federado sobre tablas lakehouse y bases existentes, sin cargar antes los datos | No almacena datos: la organización de archivos, el catálogo y cada conector fijan su rendimiento. | | [ParadeDB 0.26.1]() | 4,5/5 | AGPLv3 | Búsqueda y agregaciones analíticas dentro de PostgreSQL | Es una extensión que comparte recursos PostgreSQL, con un alcance distinto al de un warehouse distribuido. | | [Apache Druid 38.0.0]() | 4/5 | Apache-2.0 | Analítica temporal de eventos con ingesta continua | Segmentos, deep storage y metadatos requieren planes de recuperación distintos. | | [Apache Pinot 1.5.1]() | 3,5/5 | Apache-2.0 | Analítica integrada en una aplicación | La selección de índices y el diseño de tablas real-time/offline condicionan el resultado. | > [!NOTE] > > **Cómo se calculó cada calificación** > > Cinco criterios de 0, 0,5 o 1 punto. Topes: upstream archivado 1, sin versión estable en 18 meses 2, sin versión de disponibilidad general 2,5. "Edición abierta" puntúa lo que incluye la edición open source sin nivel de pago. Puntuado en octubre de 2026 con el repositorio, las versiones y la documentación oficiales; el método está en el [índice del Blog](). > > | Proyecto | Mantenimiento | Edición abierta | Madurez | Operación | Interoperabilidad | Calificación | > | :--- | :---: | :---: | :---: | :---: | :---: | :---: | > | DuckDB | 1 | 1 | 1 | 1 | 1 | 5 | > | ClickHouse | 1 | 1 | 1 | 0,5 | 1 | 4,5 | > | Apache Doris | 1 | 1 | 1 | 0,5 | 1 | 4,5 | > | StarRocks | 1 | 1 | 1 | 0,5 | 1 | 4,5 | > | Trino | 1 | 1 | 1 | 0,5 | 1 | 4,5 | > | ParadeDB | 1 | 1 | 0,5 | 1 | 1 | 4,5 | > | Apache Druid | 1 | 1 | 1 | 0 | 1 | 4 | > | OpenObserve | 1 | 0,5 | 0,5 | 1 | 1 | 4 | > | Apache Pinot | 1 | 1 | 1 | 0 | 0,5 | 3,5 | [AGPLv3 es open source](); Apache, MIT y AGPL representan elecciones de licencia distintas. Identifica la compilación y extensiones exactas. Doris documenta [excepciones de licencias de terceros](). Las ediciones cloud comerciales quedan fuera de estas etiquetas del núcleo. ## Empieza por la carga - **Archivos locales o un paso analítico dentro de una aplicación:** empezaría con DuckDB. Mediría memoria y disco temporal antes de introducir un clúster. Un informe diario no exige automáticamente un servicio de base de datos permanente. - **Una plataforma BI compartida con joins y dimensiones cambiantes:** compararía Doris y StarRocks con SQL representativo y el cliente BI real. Incluiría ClickHouse si encajan su ingesta y modelo de tablas. La compatibilidad del protocolo no demuestra semántica SQL idéntica. - **Dashboards de eventos y analítica operativa:** compararía ClickHouse, Druid y Pinot. Reproduciría intervalos temporales, selectividad de filtros, usuarios concurrentes e ingesta mientras corren las consultas. - **SQL sobre tablas lakehouse que siguen en el almacenamiento de objetos:** empezaría con Trino cuando las tablas Iceberg, Delta o Hudi son la fuente de verdad y varios motores deben leerlas. Elegiría ClickHouse, Doris o StarRocks cuando el serving de baja latencia justifica cargar los datos en su propio almacenamiento. - **Búsqueda de aplicación y agregaciones sobre datos PostgreSQL existentes:** evaluaría ParadeDB antes de crear otro pipeline de ingesta. La decisión debe incluir contención con transacciones y actualizaciones de extensiones. No los ordenaría por una única latencia publicada. Un dataset preagregado, una caché caliente y un join exacto sobre datos originales son pruebas distintas. ## Versiones y notas operativas > [!NOTE] > > **Trino — un motor de consulta, no un almacén** > > **Versión revisada: [483, publicada el 2026-07-18]().** Un coordinador planifica cada consulta y los workers leen los datos en su lugar mediante [conectores]() para Iceberg, Delta Lake, Hudi y bases relacionales. No carga ni guarda nada, así que el catálogo, el tamaño de los archivos y las particiones deciden casi todo el resultado. Las distribuciones comerciales añaden funciones que aquí no se califican. > > Consulta una tabla Iceberg particionada mientras cambian sus snapshots, mide el tiempo de planificación con un árbol de metadatos grande y detén un worker a mitad de consulta con la [ejecución tolerante a fallos]() activada. Verifica el control de acceso con el plugin que vayas a usar. > [!NOTE] > > **ClickHouse — el diseño de tablas es una decisión operativa** > > La [introducción]() describe SQL columnar, joins y replicación asíncrona. En la familia [MergeTree](), ordenación, particiones y merges en segundo plano influyen en ingesta y consultas. 26.8 es la línea LTS de agosto; 26.3 LTS sigue recibiendo parches, así que elige la línea por ventana de soporte, no por novedad. > > Probaría el tamaño real de los lotes, correcciones tardías y borrados junto con las consultas. Mediría presión de merges y retraso de réplicas. La replicación aporta copias adicionales; un backup restaurable de forma independiente sigue necesitando su propio ensayo. > [!NOTE] > > **Doris — incluir metadatos y modo de despliegue** > > La [arquitectura revisada]() describe responsabilidades frontend y backend, y distingue despliegues con almacenamiento y cómputo integrados o separados. > > Reproduciría joins y actualizaciones con el SQL del cliente de producción; después recuperaría metadatos frontend y datos juntos. Una lista menor de componentes ayuda si el equipo entiende sus dominios de fallo. Validaría las licencias de las dependencias del binario elegido. > [!NOTE] > > **StarRocks — probar vistas y lake con datos cambiantes** > > La [descripción del proyecto]() presenta ejecución MPP, motor columnar, vistas materializadas, ingesta continua y por lotes, y acceso a data lakes. > > Compararía consultas directas y vistas materializadas tras una actualización tardía de dimensión. Registraría retraso de actualización y espacio adicional, además de velocidad. Para el lake incluiría disponibilidad del catálogo, peticiones al object store y lecturas en frío. La versión 4.1.6 revisada es del 2026-09-30; 4.0.16 (con tag del 2026-09-29) es la línea anterior mantenida, así que fija la versión exacta a desplegar. > [!NOTE] > > **Druid — proteger los segmentos y su catálogo** > > El [deep storage]() de Druid conserva segmentos durables fuera de los procesos de consulta. Su [arquitectura]() separa responsabilidades de ingesta y consulta. > > Verificaría retraso de ingesta, eventos tardíos y recuperación tras perder nodos de consulta. Protegería tanto metadatos como deep storage. Si se utiliza rollup, documentaría el detalle descartado al ingerir y si el origen conserva datos suficientes para reconstruirlo. > [!NOTE] > > **Pinot — el tráfico de aplicación debe guiar el ensayo** > > El [proyecto]() se orienta a consultas analíticas en aplicaciones y admite ingesta por lotes y streaming con varios tipos de índices. > > Reproduciría tenants desbalanceados, filtros selectivos y peticiones concurrentes durante la ingesta. Probaría la transición entre datos offline y real-time buscando huecos o doble conteo. Incluiría gestión de segmentos y recuperación del clúster, además del endpoint SQL. > [!NOTE] > > **DuckDB — precisar el modelo de concurrencia** > > La [referencia de concurrencia]() distingue el modelo nativo dentro del proceso: un proceso puede leer y escribir, o varios pueden abrir la base en modo de solo lectura. Se admiten varios hilos escritores dentro de ese proceso. > > La misma referencia presenta Quack como protocolo remoto beta y DuckLake con catálogo PostgreSQL como otra vía para escritores concurrentes. Añaden componentes y contratos de almacenamiento diferentes. No extendería la restricción del archivo nativo a todos los sistemas basados en DuckDB. > [!NOTE] > > **ParadeDB — una opción AGPL dentro de PostgreSQL** > > El [código revisado]() incorpora búsqueda de texto y agregaciones mediante la extensión `pg_search`, con Tantivy y DataFusion. El límite de despliegue sigue siendo PostgreSQL. > > Probaría la combinación soportada de PostgreSQL y extensión, mantenimiento de índices y tráfico mixto de transacciones y búsquedas. Mantendría un plan de recuperación para ambos. Es una alternativa de búsqueda y analítica sobre datos existentes; esto no demuestra paridad con un warehouse distribuido. ## Un candidato AGPL especializado [OpenObserve]() 4/5 es una plataforma de observabilidad AGPLv3 para [logs, métricas y trazas]() con consultas analíticas. Lo evaluaría para búsqueda de telemetría, retención y dashboards. Su alcance difiere del de un warehouse BI general. Verifica versión y límites OSS/enterprise; la versión revisada [1.1.0]() (publicada el 2026-10-14) pertenece a su primera línea de disponibilidad general, 1.x, que empezó el 2026-09-11 y llevó SLOs y monitorización sintética a la edición abierta. Un requisito AGPL debe acotar opciones técnicamente adecuadas, sin convertir productos distintos en bases equivalentes. ## Una prueba que pueda cambiar la decisión Usa el mismo dataset de eventos y dimensión de clientes en cada candidato. Documenta particionado, índices, replicación, hardware y preprocesamiento. 1. **Corrección:** reconcilia conteos y sumas tras ingesta duplicada, un evento tardío, una dimensión actualizada y un borrado. Distingue agregaciones exactas y aproximadas. 2. **Frescura:** mide desde el evento de origen hasta su disponibilidad en consulta, además de p50/p95/p99 de consulta. Una respuesta rápida con datos antiguos puede incumplir el objetivo de negocio. 3. **Concurrencia:** ejecuta la mezcla real de consultas durante ingesta y mantenimiento; informa cachés frías y calientes por separado. 4. **Recuperación:** restaura datos, catálogo, permisos y offsets de ingesta en un entorno limpio. Compara los resultados recuperados con el origen. 5. **Costo:** incluye réplicas, índices, disco temporal, tráfico del object store, compactación y tiempo operativo. Fija los umbrales antes de probar. ## Completa el recorrido de los datos Un [object store]() puede conservar entradas y backups. Un [orquestador]() coordina cargas y reconstrucciones. Las [bases vectoriales]() cubren otra carga de recuperación de información. Mantén visibles esas responsabilidades al decidir si se justifica otro servicio. La [transformación]() define los modelos que alimentan estos motores; [BI]() presenta los resultados. Compara [formatos lakehouse]() cuando varios motores comparten tablas y [bases de grafos]() cuando importan los recorridos.