Cada vez que una empresa moderniza su plataforma de datos con Microsoft Fabric aparece la misma pregunta: ¿Lakehouse, Warehouse o Eventhouse? La respuesta corta os va a sonar si leéis este blog: no existe el almacén ideal. Existe el adecuado para cada tipo de trabajo — y la trampa está en obligar a uno solo a hacerlo todo.
Primero, el tablero: todo cae en el mismo lago
Microsoft Fabric reúne todas las cargas analíticas en una sola plataforma SaaS, y todo lo que entra acaba en el mismo sitio: OneLake, una única copia del dato. Esto importa más de lo que parece: los tres "almacenes" no son tres silos que se pelean por tus datos, sino tres formas distintas de trabajar sobre el mismo lago. La diferencia no está en el dato — está en la carga de trabajo.
Lakehouse: el flexible
El Lakehouse admite archivos y tablas: datos estructurados, semiestructurados o en bruto. Un CSV de la báscula, el JSON de una API, parquet, logs, incluso imágenes — todo aterriza en su zona de archivos, y lo que se va refinando se materializa como tablas Delta. Es el terreno natural de la ingeniería de datos y la ciencia de datos: Spark, R, SQL para trabajar; T-SQL para leer.
Cuándo elegirlo: cuando tu materia prima es variada y necesitas transformarla, explorarla o entrenar modelos sobre ella.
Warehouse: el estructurado
El Warehouse es un almacén SQL completo: T-SQL con DML y DDL al completo, escrituras transaccionales y modelos limpios pensados para el BI. Solo datos estructurados, con el orden y las garantías que exige el reporting serio. Si tu pregunta es "¿de dónde bebe mi Power BI cada lunes?", la respuesta suele estar aquí.
Cuándo elegirlo: cuando el destino es el análisis de negocio — modelos en estrella, cifras conciliadas, informes que no pueden fallar.
Eventhouse: el de tiempo real
El Eventhouse recibe los flujos según ocurren — telemetría, eventos, logs — y los deja consultables en segundos con KQL (y también T-SQL). Es la pieza para lo que no puede esperar al proceso nocturno: sensores de planta, actividad de una web, monitoreo de máquinas.
Cuándo elegirlo: cuando el valor del dato caduca en minutos y la pregunta es "¿qué está pasando ahora?".
Los tres, frente a frente
| Lakehouse | Warehouse | Eventhouse | |
|---|---|---|---|
| Uso | Ingeniería y ciencia de datos | BI y reporting | Analítica en tiempo real |
| Consulta | Spark · T-SQL (lectura) | T-SQL completo | KQL · T-SQL |
| Escrituras | Por lotes | Transaccionales | Streaming y lotes |
| Dato | De bruto a estructurado | Estructurado | Eventos · series temporales |
Debajo, el mismo lago. La diferencia es la carga de trabajo, no el dato.
La trampa (y cómo se atascan los proyectos)
No hay un almacén ideal: cada uno está diseñado para un patrón de trabajo concreto. Forzar a uno solo a cubrirlo todo es la receta clásica del proyecto atascado — el Warehouse ahogado con ficheros en bruto, o el Lakehouse haciendo de mala base para un reporting que pedía transacciones. La elección correcta la dicta la carga de trabajo, no la moda del momento.
En el mundo real: se combinan
Las soluciones maduras no eligen un almacén: los combinan, cada uno atendiendo el patrón para el que fue diseñado. Los archivos y las bases de datos entran por el Lakehouse; lo refinado alimenta al Warehouse; los eventos caen en el Eventhouse — y encima de los tres, un solo informe de Power BI que lo cuenta todo. Una copia del dato, tres motores, una sola verdad para decidir.
La misma regla de siempre
Si seguís esta serie ya conocéis nuestra conclusión de cabecera: la herramienta la elige el caso, no el catálogo. Igual que no hay "mejor herramienta de BI" sin conocer tu contexto, no hay almacén ganador en Fabric sin conocer tu carga de trabajo. Primero entender qué necesita moverse, a qué velocidad y para responder qué pregunta — y solo entonces, elegir la pieza.
Ricardo Borja es fundador de Inteleqta y consultor en ERP y Business Intelligence, certificado como Microsoft Power BI Data Analyst Associate. Una versión visual de esta guía se publicó como carrusel en su LinkedIn.