Data Warehouse

Un data warehouse —almacén de datos— no es una base de datos más grande. Es una base de datos con un trabajo distinto.

Dos trabajos que se estorban

La base de datos de tu aplicación existe para operar: registrar un pedido, cobrar una tarjeta, actualizar un inventario. Muchísimas operaciones diminutas, cada una tocando pocas filas, todas urgentes. A eso se le llama OLTP (procesamiento transaccional en línea).

El almacén existe para analizar: cuánto vendimos por región el trimestre pasado comparado con el anterior. Pocas consultas, cada una recorriendo millones de filas. A eso se le llama OLAP (procesamiento analítico en línea).

Si corres la segunda consulta contra la primera base, le arruinas el día a alguien que está intentando pagar.

Las cuatro cosas que lo definen

• Orientado a temas. Se organiza por conceptos del negocio —clientes, ventas, productos— no por las tablas que le convenían a la aplicación.
• Integrado. Junta datos de varios sistemas y los reconcilia. Si el CRM dice MX y el sistema de envíos dice México, aquí se decide cuál gana.
• Histórico. La app te dice la dirección actual del cliente. El almacén te dice también dónde vivía en 2023, porque esa venta se envió allá.
• No volátil. No se actualiza fila por fila todo el día: se carga por lotes y lo que entró se queda.

Por qué la consulta sale rápida

Casi todos los almacenes guardan la información por columnas en vez de por filas. Si tu consulta pide dos columnas de una tabla de doscientas, el motor solo lee esas dos y se ahorra el resto.

-- En un almacén columnar esto lee 2 columnas, no la tabla entera.
SELECT region, SUM(total) AS venta
FROM analitica.ventas
WHERE fecha >= '2026-01-01'
GROUP BY region;

No confundir con el data lake

Un data lake guarda archivos crudos de cualquier forma y le pone estructura hasta que alguien los lee. El almacén exige estructura antes de entrar. Hoy muchas empresas tienen los dos, y a la mezcla le pusieron lakehouse.