Tabla de Contenidos

• Qué es OLAP (y qué no es)

  • Lo que OLAP no es
• OLAP vs OLTP: la diferencia que lo explica todo

  • Por qué la orientación a columnas cambia todo
• La historia: de los cubos a lo columnar (y por qué te importa)

  • MOLAP, ROLAP, HOLAP
  • Por qué murió el cubo
  • El vocabulario que sí sobrevivió
• El esquema en estrella: cómo se modelan los datos OLAP
• Casos de uso prácticos con SQL real

  • 1. Analítica de producto: embudos de conversión
  • 2. Observabilidad: logs, métricas y trazas
  • 3. Dashboards de e-commerce y BI
  • 4. Series temporales e IoT
  • 5. Analítica de cara al usuario (embedded analytics)
  • 6. Análisis de retención y cohortes
• Los principales proveedores de OLAP en 2026

  • Motores OLAP de tiempo real (open source)
  • Data warehouses cloud gestionados
  • Motores embebidos
  • Especializados
  • Motores de consulta sobre data lakes
  • Y las capas encima
• Cómo elegir: mi criterio en cuatro preguntas
• Una reflexión sobre por qué esto importa más de lo que parece
• Conclusión
• Preguntas frecuentes

  • ¿Qué significa OLAP?
  • ¿Cuál es la diferencia entre OLAP y OLTP?
  • ¿Es PostgreSQL una base de datos OLAP?
  • ¿Un cubo OLAP sigue siendo útil en 2026?
  • ¿Es Cassandra una base de datos OLAP?
  • ¿Puedo usar OLAP en un proyecto pequeño?
  • ¿Cuánto cuesta una base de datos OLAP?

Qué es OLAP (y qué no es)

OLAP significa Online Analytical Processing, procesamiento analítico en línea. Es una categoría de carga de trabajo, no un producto concreto.

Esa distinción importa más de lo que parece. Cuando alguien dice "necesitamos una OLAP", lo que está describiendo es un patrón: consultas que escanean y agregan de millones a miles de millones de filas para responder preguntas de negocio. "Ingresos mensuales por producto y región de los últimos tres años" es una consulta OLAP tanto si la ejecutas en Excel contra un cubo de 1998 como si la lanzas contra una tabla de mil millones de filas hoy.

El término lo acuñó E. F. Codd —el mismo del modelo relacional— en un artículo de 1993 titulado Providing OLAP to User-Analysts: An IT Mandate, donde definía doce reglas para sistemas analíticos.

Un apunte honesto que casi nadie menciona: aquel artículo estaba patrocinado por Arbor Software, los fabricantes de Essbase, uno de los primeros productos OLAP. Las doce reglas describían sospechosamente bien lo que Essbase ya hacía. Fue una jugada de marketing brillante disfrazada de paper académico, y aun así la distinción de fondo que planteaba —las cargas analíticas necesitan un diseño distinto de las transaccionales— resultó ser completamente correcta y sigue definiendo el campo treinta años después.

La palabra "online" también confunde. No tiene nada que ver con internet: en 1993 significaba interactivo, en oposición a los informes por lotes que se generaban de noche.

Lo que OLAP no es

No es lo mismo que un data warehouse. OLAP es una categoría de procesamiento; un data warehouse es un patrón de infraestructura. Los warehouses se construyen para servir cargas OLAP, pero OLAP también corre en bases de datos de tiempo real, motores embebidos y capas semánticas.

No son las bases de datos "wide-column". Este es un error clásico y comprensible por el nombre. Cassandra, HBase y Bigtable se describen como "orientadas a columnas", pero internamente son almacenes de filas: agrupan filas por clave de partición y guardan las columnas como pares clave-valor dentro de cada fila. Sirven cargas OLTP con esquema flexible, no agregación analítica. Si alguien te propone Cassandra para tu dashboard, hay un malentendido.

No es sinónimo de "big data". Puedes tener una carga OLAP perfectamente legítima con 5 GB de datos. El patrón lo define la forma de las consultas, no el volumen.

OLAP vs OLTP: la diferencia que lo explica todo

OLTP (Online Transaction Processing) es lo que hacen PostgreSQL, MySQL u Oracle: leer y escribir pocas filas muy rápido, con transacciones y consistencia fuerte. "Dame el pedido 8821." "Descuenta una unidad del stock."

OLAP es lo contrario en casi todos los ejes:

	OLTP	OLAP
Almacenamiento	Por filas	Por columnas
Patrón de lectura	Pocas columnas, pocas filas	Muchas filas, pocas columnas
Patrón de escritura	Mutaciones de una fila, alta frecuencia	Inserciones masivas, casi solo append
Latencia objetivo	Milisegundos	De sub-segundo a segundos
Concurrencia	Miles de usuarios, consultas simples	Decenas o cientos, consultas complejas
Esquema	Normalizado (3NF)	Estrella o desnormalizado ancho
Pregunta típica	"¿Cuál es el estado del pedido X?"	"¿Cómo evolucionaron los pedidos por región?"
Ejemplos	PostgreSQL, MySQL, Oracle	ClickHouse, Snowflake, BigQuery, DuckDB

Los dos diseños son incompatibles por naturaleza, y esa es la razón de que existan ambos. Un motor optimizado para escribir una fila con integridad transaccional no puede estar también optimizado para escanear cuatrocientos millones y reducirlas a un número.

Por qué la orientación a columnas cambia todo

La diferencia física es sencilla de ver. Una base de datos por filas guarda esto en disco:

[id:1|país:ES|ingresos:42|fecha:...] [id:2|país:MX|ingresos:17|fecha:...]

Para sumar ingresos tienes que leer también país, fecha y las otras treinta columnas que no te interesan. Una columnar guarda cada columna por separado:

ingresos: [42, 17, 88, 12, ...]
país:     [ES, MX, ES, AR, ...]

Si tu tabla tiene 40 columnas y tu consulta usa 2, lees el 5% de los datos. Y como los valores contiguos son del mismo tipo y suelen repetirse, se comprimen muchísimo mejor: menos bytes en disco, menos I/O, consultas más rápidas.

Encima de eso, los motores modernos añaden ejecución vectorizada (procesar lotes de columnas con instrucciones SIMD en vez de fila a fila), data skipping (índices dispersos y estadísticas min/max para saltarse bloques enteros sin leerlos) y separación de cómputo y almacenamiento.

La historia: de los cubos a lo columnar (y por qué te importa)

Esta parte parece trivia de museo, pero explica por qué la documentación que encuentras en internet está llena de conceptos que ya nadie usa.

MOLAP, ROLAP, HOLAP

Durante décadas, la taxonomía OLAP estándar fue esta:

Modelo	Almacenamiento	Ruta de consulta	Fortaleza	Problema
MOLAP	Cubos pre-agregados (Essbase, Analysis Services)	MDX → consulta al cubo	Respuestas sub-segundo en dimensiones predefinidas	Builds de horas; el almacenamiento explota al añadir dimensiones; esquema rígido
ROLAP	Tablas relacionales (Snowflake, BigQuery, ClickHouse)	SQL → agregación bajo demanda	Consultas ad-hoc, dimensiones arbitrarias, esquema flexible	Más latencia por consulta, salvo que el motor sea muy rápido
HOLAP	Mezcla de ambos	Cubo para resúmenes, SQL para el detalle	Compromiso heredado dentro de stacks propietarios	Coste de operar dos sistemas

MOLAP fue el rey de los noventa y dos mil. La idea del cubo OLAP era pre-calcular todas las agregaciones posibles sobre dimensiones jerárquicas (tiempo, geografía, producto) para que consultar fuera una búsqueda en lugar de un cálculo.

Funcionaba, con dos costes brutales. El primero: los builds tardaban horas, así que tus datos siempre eran de ayer. El segundo, más insidioso: el cubo solo respondía las preguntas previstas al diseñarlo. Si un analista quería cruzar dos dimensiones que nadie había anticipado, había que rediseñar y reconstruir el cubo. Semanas para responder una pregunta nueva.

Por qué murió el cubo

La transición fue gradual. Sybase IQ lanzó un motor columnar en 1994. Vertica, construida por los autores de C-Store, salió comercialmente en 2007. Google publicó el paper de Dremel —la base de BigQuery— en 2010. ClickHouse se liberó como open source en 2016.

A finales de la década de 2010 pasó algo decisivo: las latencias que antes exigían pre-agregar en un cubo se conseguían ya sobre los datos crudos. Y en ese momento la capa del cubo dejó de ser un beneficio para convertirse en fricción pura. Todo el coste (builds lentos, rigidez, un sistema más que operar) a cambio de nada.

Los cubos no han desaparecido del todo: Essbase, Microsoft Analysis Services y MDX en Excel PowerPivot siguen vivos en grandes empresas. Pero para cualquier proyecto nuevo la respuesta es un motor columnar, y la pre-agregación, cuando hace falta, se resuelve con vistas materializadas que se calculan de forma incremental y se consultan como una tabla normal.

Mi opinión sobre por qué esto te importa aunque nunca vayas a tocar un cubo: cuando busques información sobre OLAP vas a encontrar mucho material que da por hecho el paradigma MOLAP —hablando de MDX, de dimensiones, de builds— y que te llevará a diseñar tu sistema con un modelo mental de 2003. La taxonomía sobrevive sobre todo en libros de texto y exámenes de certificación. Toma esos conceptos como historia, no como guía.

El vocabulario que sí sobrevivió

Aunque los cubos murieran, el lenguaje para hablar de consultas analíticas sigue siendo el mismo. Traducido a SQL moderno:

Roll-up (subir de nivel de agregación): pasar de ventas diarias a mensuales.

SELECT toStartOfMonth(fecha) AS mes, sum(importe) AS ingresos
FROM ventas GROUP BY mes ORDER BY mes;

Drill-down (bajar al detalle): del mes a los días de ese mes.

SELECT fecha, sum(importe) AS ingresos
FROM ventas WHERE toStartOfMonth(fecha) = '2026-07-01'
GROUP BY fecha ORDER BY fecha;

Slice (cortar una dimensión con un valor fijo): solo España.

SELECT fecha, sum(importe) FROM ventas WHERE pais = 'ES' GROUP BY fecha;

Dice (subcubo con varios filtros): España y México, categoría concreta, un trimestre.

SELECT pais, categoria, sum(importe)
FROM ventas
WHERE pais IN ('ES','MX') AND categoria = 'hardware'
  AND fecha BETWEEN '2026-04-01' AND '2026-06-30'
GROUP BY pais, categoria;

Pivot (girar filas a columnas): esto en OLAP moderno son funciones condicionales.

SELECT
    toStartOfMonth(fecha)         AS mes,
    sumIf(importe, pais = 'ES')   AS espana,
    sumIf(importe, pais = 'MX')   AS mexico,
    sumIf(importe, pais = 'AR')   AS argentina
FROM ventas GROUP BY mes ORDER BY mes;

Cinco conceptos que en los noventa requerían un servidor dedicado y un lenguaje propio, y que hoy son cinco consultas SQL.

El esquema en estrella: cómo se modelan los datos OLAP

El modelo lógico dominante en analítica es el esquema en estrella: una tabla de hechos en el centro, rodeada de tablas de dimensiones.

La tabla de hechos contiene los eventos medibles, con muchas filas y pocas columnas: una venta, un clic, una lectura de sensor. Las tablas de dimensiones contienen el contexto descriptivo: quién es ese cliente, qué categoría tiene ese producto, en qué región está esa tienda.

-- Tabla de hechos: crece sin parar
CREATE TABLE hechos_ventas (
    fecha       Date,
    producto_id UInt32,
    cliente_id  UInt32,
    tienda_id   UInt16,
    unidades    UInt32,
    importe     Decimal(12, 2)
) ENGINE = MergeTree
ORDER BY (tienda_id, fecha, producto_id);

-- Dimensión: pequeña y estable
CREATE TABLE dim_producto (
    producto_id UInt32,
    nombre      String,
    categoria   LowCardinality(String),
    marca       LowCardinality(String)
) ENGINE = MergeTree ORDER BY producto_id;

Aquí hay un matiz que separa la teoría de la práctica. En un data warehouse clásico, el esquema en estrella es dogma. En los motores OLAP columnares modernos, muchas veces conviene desnormalizar y meter categoria y marca directamente en la tabla de hechos. Suena a herejía —estás duplicando datos— pero como esas columnas se comprimen brutalmente bien con LowCardinality, el coste de almacenamiento es casi nulo y te ahorras un JOIN en cada consulta.

Mi regla: empieza desnormalizando lo que casi nunca cambia (categoría de producto, país de la tienda) y mantén como dimensión separada lo que cambia a menudo o lo que es grande.

Casos de uso prácticos con SQL real

Aquí es donde OLAP deja de ser teoría. Estos son los patrones que de verdad te vas a encontrar.

1. Analítica de producto: embudos de conversión

El caso más común en producto. Quieres saber cuánta gente pasa de ver una página a registrarse y de ahí a comprar, y dónde se cae.

En SQL estándar esto es una pesadilla de CTEs y self-joins. En un motor OLAP moderno es una función:

SELECT nivel, count() AS usuarios
FROM (
    SELECT
        usuario_id,
        windowFunnel(86400)(
            timestamp,
            evento = 'pageview',
            evento = 'signup',
            evento = 'purchase'
        ) AS nivel
    FROM eventos
    WHERE fecha >= today() - 30
    GROUP BY usuario_id
)
GROUP BY nivel
ORDER BY nivel;

windowFunnel(86400) cuenta cuántos pasos consecutivos completó cada usuario dentro de una ventana de 24 horas. El resultado te da directamente la forma del embudo.

Por qué necesitas OLAP aquí: esta consulta toca todos los eventos de todos los usuarios de un mes. En Postgres con decenas de millones de filas, es un escaneo secuencial que tumba la base de producción.

2. Observabilidad: logs, métricas y trazas

Los logs son el caso OLAP por excelencia y mucha gente no lo ve porque los asocia a Elasticsearch. Son eventos con marca de tiempo, se escriben mucho, se leen por agregación y casi nunca se actualizan.

SELECT
    toStartOfMinute(timestamp)                    AS minuto,
    servicio,
    count()                                       AS total,
    countIf(nivel = 'ERROR')                      AS errores,
    round(countIf(nivel = 'ERROR') / count(), 4)  AS tasa_error,
    quantile(0.95)(duracion_ms)                   AS p95,
    quantile(0.99)(duracion_ms)                   AS p99
FROM logs
WHERE timestamp >= now() - INTERVAL 3 HOUR
GROUP BY minuto, servicio
HAVING tasa_error > 0.01
ORDER BY minuto DESC;

Percentiles, tasas de error y agrupación por minuto en una sola pasada. Añade un TTL para que los datos de más de 90 días se borren solos y tienes una plataforma de observabilidad completa.

Nota económica que a mí me cambió las cuentas: migrar logs de una solución SaaS de observabilidad a una base OLAP autoalojada es una de las reducciones de coste más grandes disponibles para un proyecto pequeño. Los precios de las plataformas de logs se calculan por volumen ingerido, y el volumen de logs solo crece.

3. Dashboards de e-commerce y BI

El caso clásico: métricas de negocio agregadas por múltiples dimensiones.

SELECT
    toStartOfWeek(fecha)                       AS semana,
    categoria,
    sum(importe)                               AS ingresos,
    count()                                    AS pedidos,
    uniq(cliente_id)                           AS clientes,
    round(sum(importe) / count(), 2)           AS ticket_medio,
    round(sum(importe) / uniq(cliente_id), 2)  AS ingreso_por_cliente
FROM hechos_ventas
WHERE fecha >= today() - 180
GROUP BY semana, categoria
ORDER BY semana DESC, ingresos DESC;

Fíjate en uniq(): usa HyperLogLog para contar distintos de forma aproximada, con un error típico por debajo del 1% y un consumo de memoria ridículo comparado con uniqExact(). Para un dashboard de negocio, esa aproximación es perfectamente aceptable y la diferencia de rendimiento es enorme.

4. Series temporales e IoT

Sensores, métricas de infraestructura, precios de mercado. Datos que llegan a mucha frecuencia y se consultan a una resolución menor.

SELECT
    toStartOfFifteenMinutes(timestamp)  AS intervalo,
    sensor_id,
    round(avg(temperatura), 2)          AS media,
    min(temperatura)                    AS minima,
    max(temperatura)                    AS maxima,
    count()                             AS lecturas
FROM metricas_sensores
WHERE timestamp >= now() - INTERVAL 7 DAY
  AND sensor_id IN (101, 102, 103)
GROUP BY intervalo, sensor_id
ORDER BY intervalo;

El patrón que hace esto sostenible es la reducción progresiva de resolución: guardas lecturas por segundo durante una semana, por hora durante un año y por día indefinidamente. Con un TTL agregador, esto es automático.

5. Analítica de cara al usuario (embedded analytics)

El caso más exigente. No es un dashboard interno que miran tres personas: es una pestaña de "Estadísticas" dentro de tu producto que consultan todos tus clientes a la vez.

SELECT
    toDate(timestamp)     AS dia,
    count()               AS visitas,
    uniq(visitante_id)    AS visitantes,
    countIf(rebote)       AS rebotes
FROM eventos_web
WHERE tenant_id = {tenant:UInt32}      -- ¡siempre primero en el ORDER BY!
  AND timestamp >= {desde:DateTime}
GROUP BY dia
ORDER BY dia;

Aquí la clave del diseño es que tenant_id sea la primera columna de la clave de ordenación. Así cada cliente solo escanea sus propios datos, y la latencia se mantiene en milisegundos aunque la tabla tenga miles de millones de filas de todos los clientes juntos. Es la diferencia entre una funcionalidad que escala y una que se cae cuando llegan cien clientes.

6. Análisis de retención y cohortes

Cuántos usuarios que se registraron en un mes siguen activos meses después.

SELECT
    cohorte,
    mes_relativo,
    uniq(usuario_id) AS usuarios
FROM (
    SELECT
        usuario_id,
        fecha,
        toStartOfMonth(min(fecha) OVER (PARTITION BY usuario_id)) AS cohorte,
        dateDiff('month', cohorte, toStartOfMonth(fecha))         AS mes_relativo
    FROM eventos
)
GROUP BY cohorte, mes_relativo
ORDER BY cohorte, mes_relativo;

Cuidado con dónde colocas el OVER: tiene que ir pegado a min(fecha), dentro de toStartOfMonth(). Si escribes toStartOfMonth(min(fecha)) OVER (...), ClickHouse interpreta que toStartOfMonth es la función de ventana y falla con Aggregate function with name 'toStartOfMonth' does not exist.

Este tipo de consulta —ventanas sobre toda la tabla— es exactamente lo que hunde a una base de datos transaccional y lo que una columnar resuelve en un par de segundos.

Los principales proveedores de OLAP en 2026

El mercado se divide en cinco categorías bastante nítidas. Los ordeno por cómo encajan con proyectos reales, no por cuota de mercado.

Motores OLAP de tiempo real (open source)

Latencia sub-segundo, ingesta continua, pensados para dashboards en vivo y analítica embebida.

ClickHouse es la referencia de la categoría. Columnar, un solo binario, licencia Apache 2.0, escala desde un portátil hasta cientos de nodos. Es la opción por defecto para self-hosting y tiene servicio gestionado propio (ClickHouse Cloud). Si quieres el detalle, tengo una guía completa de ClickHouse.

Apache Druid lleva años haciendo analítica de series temporales en tiempo real a gran escala. Muy potente para ingesta desde Kafka, pero con un coste operativo alto: seis tipos de proceso más ZooKeeper.

Apache Pinot nació en LinkedIn para servir analítica a cientos de millones de usuarios. Es el más específicamente diseñado para latencia mínima con concurrencia muy alta, con la misma pega de complejidad operativa.

StarRocks y Apache Doris son primos cercanos, con MPP columnar y un optimizador de JOINs más fuerte que el de ClickHouse. Buena elección si tu esquema es un warehouse normalizado.

Data warehouses cloud gestionados

Cero operaciones, escala prácticamente ilimitada, facturación por consumo.

Snowflake popularizó la separación de cómputo y almacenamiento y domina el segmento empresarial. Muy maduro en gobierno de datos y permisos. Cobra por tiempo de cómputo del warehouse.

Google BigQuery es serverless de verdad: no gestionas cluster, escribes SQL. Cobra principalmente por datos escaneados, lo que hace que las consultas mal escritas salgan caras.

Amazon Redshift es la opción del ecosistema AWS. Más antiguo, requiere más tuning manual, pero se integra de forma nativa con el resto de servicios de Amazon.

Databricks SQL es la referencia de la arquitectura lakehouse, uniendo ingeniería de datos, machine learning y analítica sobre el mismo almacenamiento. Fuerte cuando hay datos no estructurados y flujos de IA en juego.

Azure Synapse completa el trío de hiperescalares para quien ya vive en Microsoft.

Mi aviso sobre esta categoría, repetido de la comparativa pero relevante aquí: el modelo de precio por consumo castiga justamente el patrón de la analítica interactiva, muchas consultas pequeñas y frecuentes. Un dashboard con auto-refresh puede generar una factura desproporcionada. Si trabajas con presupuesto ajustado, la factura variable es un riesgo de negocio, no solo técnico.

Motores embebidos

Sin servidor, corren dentro de tu proceso.

DuckDB es SQLite para analítica: pip install duckdb y ya tienes un motor columnar vectorizado con dialecto compatible con PostgreSQL. Lee Parquet y CSV directamente. Para datasets que caben en una máquina, es imbatible en simplicidad. MotherDuck es su capa cloud.

chDB es el motor de ClickHouse embebido en Python, con API estilo pandas.

Especializados

kdb+ domina el trading de alta frecuencia. Extremadamente rápido en series temporales, con un lenguaje propio (q) y un precio a la altura de su nicho.

QuestDB es open source y orientado a series temporales con SQL extendido.

TimescaleDB —de la empresa que en 2025 pasó a llamarse TigerData, aunque la extensión open source mantiene el nombre— convierte PostgreSQL en una base de series temporales. Si ya usas Postgres y tu volumen es moderado, es la migración de menor fricción posible.

Firebolt y SingleStore compiten en el nicho de rendimiento alto con gestión cloud.

Motores de consulta sobre data lakes

Trino (antes PrestoSQL) y Apache Spark SQL consultan datos que viven en formatos abiertos como Apache Iceberg, Delta Lake o Parquet sobre almacenamiento de objetos. No son bases de datos: son motores que ponen SQL encima de tus archivos.

Esta categoría está difuminando la frontera entre "data lake" y "base de datos OLAP". Muchos motores columnares —ClickHouse entre ellos— ya leen Iceberg y Parquet directamente, lo que significa que puedes consultar tu lago sin ingerir nada.

Y las capas encima

Merece la pena mencionar que OLAP es la capa de procesamiento, no la de presentación. Tableau, Looker, Power BI, Metabase y Grafana son herramientas de BI que se conectan a una base OLAP para ejecutar las consultas por debajo. La base pone velocidad y estructura; el BI pone la interfaz.

Cómo elegir: mi criterio en cuatro preguntas

Traducido a decisiones prácticas.

¿Tus datos caben en una máquina (digamos, menos de unos cientos de GB)? Empieza por DuckDB. Cero operaciones, rendimiento excelente y SQL familiar. Es la recomendación que más gente ignora y la que más veces resulta correcta.

¿Necesitas un servicio compartido con escrituras continuas y varios lectores? ClickHouse. Es el mejor punto de equilibrio entre rendimiento y complejidad operativa que existe hoy, y funciona en un VPS modesto.

¿Ya vives en PostgreSQL y tu volumen es moderado? TimescaleDB. Añades una extensión en vez de un servicio nuevo. La opción aburrida suele ser la correcta.

¿Tienes equipo, presupuesto y prioridad en cero infraestructura? Snowflake, BigQuery o Databricks. Configura alertas de coste el primer día.

Y la pregunta previa a todas: ¿de verdad necesitas OLAP? Si tu tabla más grande tiene dos millones de filas y tus consultas tardan 200 ms en Postgres, la respuesta es no. Añadir un sistema analítico es añadir un servicio que mantener, respaldar y monitorizar. La señal de que ha llegado el momento es concreta: cuando una agregación central para tu producto tarda más de cinco segundos y ya has intentado indexarla.

Una reflexión sobre por qué esto importa más de lo que parece

Durante años pensé que "OLAP" era jerga corporativa para gente que trabaja con cubos en bancos. Es un prejuicio bastante extendido entre desarrolladores, y me costó caro.

Lo que me hizo cambiar de opinión fue darme cuenta de que casi todo producto digital genera datos de eventos, y casi ninguno los aprovecha porque la infraestructura por defecto —una base de datos relacional— hace que consultarlos sea doloroso. Así que se acaban tirando, o se guardan en una tabla que nadie se atreve a tocar, o se paga a un SaaS de analítica que te da el 10% de lo que podrías tener.

Adoptar una base OLAP no cambió lo que podía medir. Cambió la frecuencia con la que preguntaba. Cuando una consulta tarda 40 segundos, exploras dos hipótesis por sesión. Cuando tarda 300 milisegundos, exploras veinte. Y esa diferencia de frecuencia es la que acaba produciendo hallazgos que no buscabas.

Ese es el argumento real a favor de OLAP, y no aparece en ningún benchmark: no es que las consultas vayan más rápido, es que haces más preguntas.

Conclusión

OLAP no es una tecnología concreta ni una moda: es la categoría de sistemas construidos para responder preguntas sobre grandes volúmenes de datos, y lleva treinta años existiendo bajo distintos nombres. Lo que ha cambiado radicalmente es la implementación: de cubos rígidos que se construían de noche a motores columnares que agregan sobre datos crudos en milisegundos.

Para un proyecto pequeño hoy, esa evolución significa algo muy concreto: capacidades analíticas que en 2005 requerían un equipo dedicado y una licencia de seis cifras hoy caben en un binario que corre en un VPS de veinte euros al mes.

Si quieres pasar de la teoría a algo funcionando, el camino más corto es:

• Qué es ClickHouse y cómo instalarlo — de cero a consultas reales en cinco minutos.
• Alternativas a ClickHouse: comparativa con tabla — para elegir con criterio entre las opciones de este post.
• Guía avanzada de optimización — vistas materializadas, projections, codecs y TTL.

---

Preguntas frecuentes

¿Qué significa OLAP?

Online Analytical Processing. Designa una categoría de cargas de trabajo analíticas —agregaciones y agrupaciones sobre millones de filas— y los sistemas construidos para servirlas. El término lo acuñó E. F. Codd en 1993, y "online" significa interactivo, no relacionado con internet.

¿Cuál es la diferencia entre OLAP y OLTP?

OLTP está orientado a filas y optimizado para leer y escribir pocos registros con latencia de milisegundos. OLAP está orientado a columnas y optimizado para escanear y agregar millones de filas. Sus diseños son opuestos, por eso conviven en la misma arquitectura en lugar de sustituirse.

¿Es PostgreSQL una base de datos OLAP?

No. PostgreSQL es OLTP: su almacenamiento por filas y sus índices B-tree están pensados para búsquedas puntuales y escrituras pequeñas. Extensiones como TimescaleDB, Citus o pg_duckdb añaden capacidad analítica limitada, pero a escala el patrón estándar es Postgres para escrituras más una base OLAP para lecturas, conectadas por CDC.

¿Un cubo OLAP sigue siendo útil en 2026?

Solo en entornos heredados. Los motores columnares logran latencias equivalentes calculando las agregaciones bajo demanda, y cuando hace falta pre-agregar se usan vistas materializadas incrementales en lugar de cubos.

¿Es Cassandra una base de datos OLAP?

No. Cassandra, HBase y Bigtable son almacenes "wide-column" pero orientados a filas en el nivel de almacenamiento. Sirven cargas OLTP con esquema flexible, no agregación analítica.

¿Puedo usar OLAP en un proyecto pequeño?

Sí, y cada vez es más fácil. DuckDB corre como librería dentro de tu aplicación y ClickHouse como un único binario en un VPS. Ya no hace falta infraestructura empresarial para empezar.

¿Cuánto cuesta una base de datos OLAP?

Las opciones open source autoalojadas (ClickHouse, DuckDB, StarRocks) no tienen coste de licencia; pagas el servidor y tu tiempo de operación. Los servicios gestionados cobran por cómputo y almacenamiento, con modelos que varían mucho: BigQuery cobra sobre todo por datos escaneados y Snowflake por tiempo de cómputo activo.