Redefiniendo OLAP: la distribución en 2026
Hace diez años, OLAP era sinónimo de grandes clústeres distribuidos y centralizados como Vertica, Redshift y Snowflake. El panorama de 2026 es completamente diferente. ClickHouse Cloud, ahora serverless, logra escalar en segundos; DuckDB procesa cientos de gigabytes con un solo proceso; y la versión WASM de DuckDB en el navegador permite consultar Parquet en S3 directamente desde el frontend. Esto ya es una realidad.
De las 23 consultas de arquitectura de datos que KGA recibió en el Q1 de 2026, solo 9 optaron desde el inicio por el enfoque tradicional de centralizar todo en Snowflake o BigQuery. Las otras 14 eligieron una arquitectura híbrida: un data warehouse central (Snowflake o BigQuery) para análisis corporativos, y una capa OLAP ligera local (ClickHouse o DuckDB) para el trabajo de campo. En muchos casos, separar responsabilidades redujo el costo total entre un 30 % y un 50 %.
La posición de ClickHouse Cloud en 2026
ClickHouse Cloud ha alcanzado el mejor equilibrio entre rendimiento y facilidad operativa gracias al soporte serverless de 2024, a SharedMergeTree (separación completa de cómputo y almacenamiento) de 2025, y a la automatización de Query Condition Cache y Parallel Replica de 2026. En un cliente de publicidad digital de KGA, este stack permite ingestar dos millones de eventos por segundo y responder consultas de dashboard en menos de un segundo, con un costo un 40 % inferior al anterior.
ClickHouse sobresale cuando se cumplen todas estas características a la vez:
- Escrituras append-only de tipo series de tiempo o logs de eventos: impresiones publicitarias, eventos de juegos, telemetría IoT, trazas APM, analítica web.
- Consultas de agregación sobre una o pocas tablas: GROUP BY, SUM, COUNT, PERCENTILE.
- Dashboards interactivos de baja latencia: casos donde se requiere respuesta en el P95 por debajo de los 500 ms.
- Agregaciones sobre dimensiones de alta cardinalidad: análisis por user_id, session_id, trace_id.
Por el contrario, los workloads con muchos joins entre tablas, frecuentes updates o deletes y exploración ad hoc son más naturales en Snowflake o BigQuery. ClickHouse ha mejorado considerablemente en joins con Parallel Hash Join y Grace Hash Join, pero en esquemas estrella de más de 10 tablas los otros MPP siguen siendo más estables.
El impacto de DuckDB 1.2
DuckDB es una base de datos OLAP in-process que se puede incrustar como librería en cualquier aplicación. Sus tres avances más importantes en la versión 1.2 son:
Modo servidor HTTP: DuckDB, hasta ahora solo una librería, puede ahora levantarse como servidor HTTP. Se pueden enviar consultas desde Python, Go o TypeScript por HTTP y recibir los resultados en JSON o Arrow IPC. Es una alternativa más rápida de montar que ClickHouse para una API de datos ligera.
Lectura y escritura de Iceberg y Delta: desde la versión 1.1 DuckDB puede leer Iceberg; desde la 1.2, también escribirlo. Es posible leer y escribir directamente tablas Iceberg en S3, lo que habilita un acceso ligero al lakehouse.
Rendimiento WASM: DuckDB-WASM en el navegador, con optimizaciones SIMD y soporte de Workers paralelos, alcanza el 60–70 % del rendimiento de la versión de escritorio. Herramientas de BI como Observable, Evidence.dev y Perspective se construyen sobre esto; analizar 100 GB de Parquet directamente en el navegador es ya una realidad.
En un cliente de gobierno local de KGA implementamos un dashboard de datos abiertos con DuckDB-WASM: el navegador lee directamente los Parquet públicos en S3 y realiza toda la agregación y visualización del lado del cliente. El costo de cómputo en el servidor es cero, el costo de escala es prácticamente cero, y la solución superó pruebas de carga hasta un millón de usuarios.
La consolidación de MotherDuck
MotherDuck es un servicio gestionado construido sobre DuckDB que, tras su beta en 2024 y su GA en 2025, se ha consolidado en 2026 como alternativa real a Snowflake y BigQuery para workloads analíticos de tamaño mediano.
Su característica principal es la «ejecución híbrida»: parte de la consulta (lectura de archivos, filtros) corre en la nube y el resto en el DuckDB local, minimizando la transferencia de datos y aprovechando los recursos de cómputo locales. Para los desarrolladores de Python, poder hacer un `attach` de MotherDuck en un notebook y hacer JOIN sin fricción entre tablas masivas en la nube y archivos CSV o Parquet locales es una experiencia que ningún otro servicio ofrece.
El precio también es atractivo: datos menores de 10 GB caben en la capa gratuita; entre 100 GB y 1 TB el costo es aproximadamente un quinto del de Snowflake. Sin embargo, a partir de los 10 TB, o para dashboards con más de 50 usuarios concurrentes, Snowflake o ClickHouse son opciones más directas.
La apuesta independiente de Turso y LibSQL
Turso es una base de datos SQL distribuida en el edge basada en LibSQL, un fork de SQLite. Estrictamente hablando es más OLTP que OLAP, pero la extensión Analytics introducida en 2026 (similar a AlloyDB Columnar, que combina almacenamiento por filas y por columnas) le permite manejar análisis de escala pequeña a mediana.
Su diferencial es la replicación del esquema de base de datos en edges de todo el mundo en una configuración multi-tenant, lo que permite consultas con latencias de un solo milisegundo desde Cloudflare Workers o Vercel Edge Functions. Es ideal para fabricantes de dispositivos IoT o para SaaS con dashboards que necesitan alta respuesta para usuarios geográficamente distribuidos.
Como solución OLAP pura es inferior a DuckDB o ClickHouse, pero es la primera opción cuando se quiere combinar OLTP y análisis ligero en una sola base de datos, o cuando se necesita despliegue en el edge.
Almacenamiento por niveles y diseño hot/cold
En 2026, el almacenamiento por niveles (tiered storage) se ha vuelto imprescindible en la operación OLAP. ClickHouse Cloud, con SharedMergeTree, estandariza S3 o GCS como almacenamiento primario y NVMe local como capa de caché. Snowflake y BigQuery tienen una estructura similar, pero ClickHouse permite afinar explícitamente la política de caché, lo que lo diferencia.
En un cliente publicitario de KGA diseñamos tres niveles: «últimos 30 días = hot (NVMe siempre en caché), 31–180 días = warm (S3, se carga en NVMe bajo demanda), más de 181 días = cold (S3 Glacier, se consulta directamente con Athena)». Esto redujo el costo de almacenamiento en un 80 %. El rendimiento de hot y warm es prácticamente idéntico; cold es 10–20 veces más lento, pero la necesidad de consultar datos de más de 180 días de forma interactiva es rara y, por tanto, aceptable.
Problemas frecuentes en workloads en japonés
Cinco problemas típicos en el análisis de datos de empresas japonesas:
1. Zonas horarias: la mezcla de JST (UTC+9) y UTC sigue causando bugs de desfase de un día en los límites de fecha. En ClickHouse se resuelve con el parámetro de zona horaria `'Asia/Tokyo'` en `DateTime64`; en BigQuery y Snowflake, almacenando en UTC y convirtiendo en el momento de la visualización. DuckDB estabilizó `TIMESTAMPTZ` a partir de la versión 1.2.
2. Caracteres multibyte y collation: los nombres de clientes y productos con espacios de ancho completo, caracteres alfanuméricos de ancho variable y kanji en desuso requieren más que una simple comparación de bytes UTF-8. ClickHouse lo resuelve con la extensión ICU; DuckDB, con funciones de normalización NFKC. Si se usan como clave de agregación, lo correcto es incluir un pipeline de normalización previo a la ingesta.
3. Números en kanji y el calendario japonés: expresiones como «令和六年三月» son inevitables en proyectos gubernamentales. Lo correcto es no resolverlo a nivel de SQL, sino normalizar a ISO 8601 al ingestar.
4. CP932 / Shift_JIS mezclado: todavía aparece en exportaciones CSV de sistemas legados. El parámetro `encoding` de `read_csv` en DuckDB 1.2 pasó a GA oficial; en ClickHouse se convierte con la función `INPUT`.
5. Katakana de ancho medio: todavía existe en datos bancarios. Convertir con NKFC hace que «ｶ» y «カ» sean equivalentes, pero puede causar problemas si el dato original usa el ancho medio como clave. Las reglas de conversión deben definirse y documentarse desde el principio.
Arquitectura recomendada para 2026
El «modern data stack» que KGA recomienda a sus clientes se divide así:
- DWH central (Snowflake / BigQuery / Databricks): análisis transversales, finanzas, métricas de negocio. Se expone externamente con escritura en Iceberg (lakehouse).
- OLAP en tiempo real (ClickHouse Cloud): dashboards con respuesta en segundos, eventos de publicidad, juegos e IoT, APM.
- Notebooks / análisis local (DuckDB + MotherDuck): exploración de data scientists, generación de data marts intermedios.
- Visualización en el navegador (DuckDB-WASM): dashboards públicos, frontend ligero de BI interno.
- OLTP + Analytics en el edge (Turso): base de datos por tenant para SaaS con usuarios geográficamente distribuidos.
La integración de estas cinco capas a través de una Semantic Layer (como Cube.dev) y la posibilidad de consultarlas todas en lenguaje natural mediante agentes LLM es el punto de llegada del «modern data stack» de 2026. En lugar de concentrarlo todo en un solo proveedor, la arquitectura más eficiente en costo y escalable a largo plazo es elegir la herramienta óptima para cada rol y conectarlas a través de metadatos y semántica.