TL;DR: En Microsoft Fabric, elige Warehouse si tu equipo trabaja con T-SQL y necesita escrituras transaccionales (INSERT/UPDATE/DELETE) y modelado relacional clásico. Elige Lakehouse si trabajas con archivos, Spark/Python, datos semiestructurados o ciencia de datos. Ambos guardan los datos en OneLake como Delta-Parquet, ambos exponen un endpoint SQL de lectura y ambos pueden alimentar un modelo semántico Direct Lake en Power BI. La diferencia no es el almacenamiento: es cómo escribes y quién lo opera.
Lakehouse vs Warehouse: tabla comparativa
La diferencia central es el motor de escritura y el perfil del equipo: el Warehouse es T-SQL transaccional puro, el Lakehouse es Spark y archivos. Todo lo demás —almacenamiento, formato abierto, consumo en Power BI— es prácticamente idéntico porque ambos viven sobre OneLake. Esta tabla resume las decisiones que más se repiten en la comunidad de Fabric, donde estos hilos acumulan más de 90 000 vistas.
| Criterio | Lakehouse | Warehouse |
|---|---|---|
| Motor principal | Spark (PySpark, Scala, Spark SQL) | T-SQL (motor de Warehouse) |
| Escritura | Notebooks, Dataflows Gen2, pipelines | T-SQL: INSERT, UPDATE, DELETE, MERGE |
| Endpoint SQL | Solo lectura (SQL analytics endpoint) | Lectura y escritura |
| Transacciones multi-tabla | No (a nivel T-SQL) | Sí, ACID multi-tabla |
| Datos no estructurados / archivos | Sí (carpeta Files) | No |
| Ciencia de datos / ML | Sí (notebooks, MLflow) | Limitado |
| Almacenamiento | OneLake, Delta-Parquet | OneLake, Delta-Parquet |
| Consumo en Power BI | Direct Lake / DirectQuery / Import | Direct Lake / DirectQuery / Import |
| Perfil de equipo | Data engineers, Python | Analistas y desarrolladores SQL |
¿Qué es un Lakehouse en Microsoft Fabric?
Un Lakehouse es un elemento de Fabric que combina un data lake (carpeta de archivos) con tablas Delta consultables, todo almacenado en OneLake. Se opera principalmente con Spark mediante notebooks (PySpark, Scala o Spark SQL), Dataflows Gen2 y pipelines. Incluye un endpoint SQL de solo lectura para consultar las tablas con T-SQL, pero no para modificarlas.
El Lakehouse brilla cuando los datos llegan en formatos diversos —CSV, JSON, Parquet, archivos crudos— o cuando necesitas transformarlos con código. La carpeta Files guarda lo no estructurado; la carpeta Tables guarda tablas Delta que ya tienen esquema. Una ingesta típica escribe una tabla Delta desde un notebook con pocas líneas:
# Escribir una tabla Delta en el Lakehouse desde un notebook de Fabric
df = spark.read.format("csv").option("header", "true").load("Files/ventas/2026.csv")
df.write.format("delta").mode("overwrite").saveAsTable("ventas")Este enfoque es el preferido por equipos de ingeniería de datos y ciencia de datos, porque el mismo notebook que limpia los datos puede entrenar un modelo con MLflow. La contrapartida: para escribir con T-SQL puro no sirve, porque su endpoint SQL es de solo lectura.
¿Qué es un Warehouse en Microsoft Fabric?
Un Warehouse es un almacén de datos relacional completo gobernado por T-SQL, con soporte para DDL y DML (CREATE TABLE, INSERT, UPDATE, DELETE, MERGE) y transacciones ACID multi-tabla. Igual que el Lakehouse, persiste sus datos en OneLake como Delta-Parquet, pero a diferencia de él, sí permite escritura transaccional directa con SQL.
El Warehouse es la opción natural para equipos que ya dominan SQL Server o Azure Synapse y quieren un modelo dimensional clásico (hechos y dimensiones) sin tocar Spark, como detalla la guía de decisión oficial de Microsoft Learn. Toda la operación cabe en sentencias T-SQL conocidas:
-- Crear y poblar una tabla en el Warehouse con T-SQL
CREATE TABLE dbo.Ventas (Fecha DATE, Producto VARCHAR(50), Importe DECIMAL(18,2));
INSERT INTO dbo.Ventas
SELECT Fecha, Producto, Importe
FROM dbo.Staging_Ventas
WHERE Importe > 0;Como cualquier almacén relacional, soporta procedimientos almacenados, vistas y control de transacciones. La limitación frente al Lakehouse es el otro extremo: no ejecuta Spark ni maneja archivos no estructurados, así que para ingestar JSON anidado o entrenar modelos te quedas corto.
¿Cuándo usar un Lakehouse?
Usa un Lakehouse cuando tu equipo trabaja con código (Python/Spark), los datos llegan en archivos o formatos semiestructurados, o necesitas ciencia de datos y machine learning. Es la opción por defecto para la capa de ingesta y transformación (bronce y plata) en una arquitectura medallion, donde el volumen y la variedad mandan sobre la pureza relacional.
Escenarios claros para Lakehouse:
- Ingesta de archivos crudos (logs, CSV, JSON, imágenes) que aún no tienen esquema fijo.
- Transformaciones complejas que se expresan mejor en PySpark que en SQL.
- Machine learning dentro del mismo entorno (notebooks + MLflow).
- Equipos de data engineering acostumbrados a Spark y a Git para notebooks.
- Streaming y cargas de gran volumen donde Spark escala mejor.
Si tu pregunta es «¿cómo proceso estos archivos y los dejo listos para analizar?», la respuesta casi siempre es Lakehouse.
¿Cuándo usar un Warehouse?
Usa un Warehouse cuando tu equipo es SQL-first y necesita escrituras transaccionales, un modelo dimensional gobernado o procedimientos almacenados. Es la opción para la capa de servicio (oro): datos ya limpios, modelados en hechos y dimensiones, listos para reporting empresarial con garantías ACID.
Escenarios claros para Warehouse:
- Equipos con experiencia en T-SQL (SQL Server, Synapse) que no quieren aprender Spark.
- Cargas transaccionales que requieren
UPDATE/DELETE/MERGEcon integridad multi-tabla. - Modelado dimensional clásico (esquema estrella) servido a Power BI.
- Procedimientos almacenados y vistas como lógica de negocio reutilizable.
- Gobernanza relacional con permisos a nivel de objeto SQL.
Si tu pregunta es «¿cómo sirvo datos limpios y consistentes para el reporting corporativo?», el Warehouse suele ser la respuesta.
¿Puedo usar Lakehouse y Warehouse a la vez?
Sí, y es el patrón recomendado en proyectos serios: Lakehouse para ingesta y transformación, Warehouse para servir. Como ambos viven en OneLake, un elemento puede consultar al otro sin copiar datos mediante el modelo de «una sola copia» (One Copy) y los shortcuts, que referencian datos de otro item como si fueran locales.
En una arquitectura medallion típica:
- Bronce/Plata (Lakehouse): notebooks ingieren y limpian archivos en tablas Delta.
- Oro (Warehouse): T-SQL modela hechos y dimensiones leyendo desde el Lakehouse vía shortcut o cross-database query.
- Consumo (Power BI): un modelo semántico Direct Lake lee directo de OneLake.
Esta complementariedad es la razón por la que el artículo base de cómo OneLake, Lakehouse y Warehouse se unen en una sola base analítica es lectura previa recomendada: la decisión no es «uno u otro» para siempre, sino «cuál para cada capa».
Lakehouse, Warehouse y Power BI: el papel de Direct Lake
Tanto el Lakehouse como el Warehouse pueden alimentar un modelo semántico en modo Direct Lake, que lee los archivos Delta-Parquet de OneLake directamente, sin importar datos ni pagar la latencia de DirectQuery. Es lo mejor de ambos mundos: rendimiento cercano a Import sin el coste de refrescos.
Direct Lake cambia la conversación clásica de «Import vs DirectQuery»: si tus datos ya están en OneLake (vía Lakehouse o Warehouse), Power BI los consulta como vectores en memoria que se cargan bajo demanda. Para el lector que viene de Power BI tradicional, esto significa que la elección de Lakehouse o Warehouse no condiciona el rendimiento del informe, sino la forma de prepararlo. La optimización V-Order que Fabric aplica al escribir Parquet es la que hace posible esa lectura rápida en ambos casos.
Errores y malentendidos comunes
La mayoría de la confusión nace de pensar que el almacenamiento los diferencia (no es así: ambos usan OneLake) o de asumir que el endpoint SQL del Lakehouse permite escribir. Estos son los malentendidos que más aparecen en la comunidad:
| Malentendido | Realidad |
|---|---|
| «El Warehouse es más rápido porque no es un lake» | Ambos guardan Delta-Parquet en OneLake; el rendimiento depende del diseño, no del tipo |
«Puedo hacer INSERT en el Lakehouse con T-SQL» |
No: su endpoint SQL es de solo lectura; escribe con Spark o Dataflows |
| «Tengo que elegir uno para todo el proyecto» | No: lo común es Lakehouse para ingesta y Warehouse para servir |
| «Necesito copiar datos del Lakehouse al Warehouse» | No: usa shortcuts y cross-query; OneLake es una sola copia |
| «Direct Lake solo funciona con Warehouse» | Funciona con ambos siempre que los datos estén en OneLake |
Preguntas frecuentes
¿Lakehouse o Warehouse para empezar en Fabric? Si tu equipo sabe SQL y los datos ya son relacionales, empieza con Warehouse. Si llegan archivos o necesitas Python/Spark, empieza con Lakehouse. En la duda, un Lakehouse es más flexible para ingesta y siempre puedes añadir un Warehouse para la capa de servicio.
¿El Lakehouse puede escribirse con T-SQL? No. El Lakehouse expone un SQL analytics endpoint de solo lectura. Para escribir usas notebooks Spark, Dataflows Gen2 o pipelines. El Warehouse sí admite escritura T-SQL completa.
¿Cuál es más barato? El coste en Fabric depende de las Capacity Units (CU) consumidas, no del tipo de item. Una carga Spark pesada en un Lakehouse puede consumir más que un Warehouse bien indexado, o al revés. El factor decisivo es el patrón de uso, no la etiqueta.
¿Puedo consultar un Warehouse desde un Lakehouse y viceversa? Sí. Gracias a OneLake y a las cross-database queries, un Warehouse puede leer tablas de un Lakehouse del mismo workspace sin copiarlas, y los notebooks pueden leer del Warehouse vía el endpoint.
Conclusión
Lakehouse y Warehouse en Microsoft Fabric no compiten: cubren extremos distintos del mismo flujo. El Lakehouse manda en ingesta, archivos, Spark y ciencia de datos; el Warehouse manda en T-SQL transaccional, modelado relacional y servicio empresarial. Como ambos viven en OneLake y ambos alimentan Direct Lake, la mejor arquitectura suele usar los dos: Lakehouse para preparar, Warehouse para servir.
Una vez tus datos están listos en Fabric, el siguiente paso es modelarlos y analizarlos con DAX en Power BI. Si quieres dominar ese modelado relacional y las medidas que dan vida a tus informes, este curso te lleva paso a paso:
Deja una respuesta