Empieza por el uso, no por la herramienta. Define qué decisiones tienen que sostener tus datos y qué perfiles los consultan, y recién ahí eliges. Un lakehouse conviene cuando trabajas con datos variados y transformaciones sobre archivos; un warehouse conviene cuando tu carga es analítica relacional con SQL. En Microsoft Fabric ambos viven sobre OneLake, así que la decisión es de topología, no de plataforma.
¿Por qué la primera pregunta no es técnica?
La tentación es abrir un comparativo de features y elegir la casilla con más marcas. Es el orden equivocado. Primero se ordenan las métricas y las decisiones, y después las herramientas. La arquitectura de datos existe para sostener una única verdad: que dirección y equipo vean los mismos números sin discutir de dónde salieron.
Por eso el punto de partida es un inventario de uso:
- ¿Qué decisiones de negocio depende de estos datos?
- ¿Quién los consulta y con qué herramienta (Excel, Power BI, una IA)?
- ¿Qué tan estructurados llegan las fuentes?
- ¿Va a ser un proyecto pequeño o algo que escale por áreas?
Con esas respuestas, la elección entre lakehouse y warehouse casi se responde sola.
¿Qué resuelve cada uno?
Un lakehouse guarda los datos como archivos en el lago y les da una capa de tabla encima. Es fuerte cuando entran datos variados (estructurados y semiestructurados) y necesitas transformarlos con código o flujos antes de exponerlos. Es el hogar natural de la arquitectura medallion: capa Bronze (crudo), Silver (limpio) y Gold (listo para consumo).
Un warehouse ofrece una experiencia relacional con SQL completo sobre esos mismos datos. Es fuerte cuando la carga es analítica clásica: tablas modeladas, consultas SQL, cálculos sobre un esquema estable que ya está ordenado.
La buena noticia en Microsoft Fabric: ambos escriben y leen sobre OneLake, la base común de la plataforma. No estás comprando dos silos. Estás eligiendo la puerta de entrada más cómoda para tu tipo de trabajo, y el dato sigue siendo uno solo.
¿Lakehouse o warehouse? Tabla de decisión
Usa esta comparación como criterio, no como veredicto:
| Criterio | Lakehouse | Warehouse |
|---|---|---|
| Tipo de datos | Variados: archivos, estructurados y semiestructurados | Principalmente relacional y estructurado |
| Forma de trabajar | Transformación sobre archivos, código y flujos | SQL relacional sobre tablas modeladas |
| Encaje con medallion | Natural para Bronze, Silver y Gold | Suele consumir la capa Gold ya curada |
| Perfil de equipo | Ingeniería de datos y transformación | Analistas y consultas SQL |
| Punto fuerte | Flexibilidad de ingesta y preparación | Consulta analítica ordenada y directa |
En la práctica muchas soluciones usan las dos: el lakehouse prepara y cura, el warehouse expone lo curado para consumo analítico. No es una guerra de bandos, es una división de responsabilidades. Si quieres afinar ese criterio de elección, revisa cómo elegir entre lakehouse y warehouse en Fabric con criterio.
¿Cómo evitar sobre-diseñar desde el primer día?
Uno de los errores más caros es montar una topología compleja cuando el proyecto todavía es chico. La regla es simple: no todo cliente necesita una arquitectura elaborada desde el día uno.
- Si el proyecto es pequeño, se simplifica. Un solo entorno, pocas capas, foco en que los números que ve dirección queden confiables.
- Si el proyecto va a escalar, se define desde el inicio la separación por entorno, capa o dominio, y se registran propietarios, descripciones, sensibilidad y señales de confianza.
Los workspaces de Fabric ayudan a ordenar esa separación de responsabilidades sin duplicar la plataforma. Y los shortcuts permiten referenciar datos internos o externos sin copiarlos, dejando visible de dónde proviene cada activo.
¿Dónde entra el gobierno en esta decisión?
Elegir lakehouse o warehouse resuelve el cómo se procesan los datos. Pero unos números confiables no se sostienen solo con procesamiento: necesita que cada activo tenga contexto, propietario y confianza. Ahí entra OneLake Catalog, que reúne descubrimiento, gobierno y seguridad sobre todo lo que publicas. Si te interesa el lado práctico de dejarlo montado, mira cómo implementar OneLake y el catálogo de datos paso a paso.
Con el catálogo puedes:
- Explorar los elementos disponibles y entender qué contiene cada uno.
- Revisar confianza y linaje: de dónde viene el dato y por dónde pasó.
- Gobernar los activos y centralizar el acceso con roles coherentes.
- Distribuir responsabilidades por dominio, alineadas a las áreas de negocio.
El modelo de control de acceso de OneLake explica cómo se combinan los roles, los permisos de cada elemento y la seguridad del motor. Decidir la topología sin decidir el gobierno deja la mitad del trabajo hecho.
¿Y el modelo semántico?
Ni el lakehouse ni el warehouse definen por sí solos qué significa "venta", "margen" o "cliente activo". Eso lo define el modelo semántico, la capa donde el negocio acuerda qué significa cada métrica. Es la capa donde acuerdas que un número quiere decir lo mismo para todos, se consulte desde Excel, Power BI o una IA.
Por eso la secuencia sana es: primero el criterio (qué decisiones y qué métricas), después la topología (lakehouse, warehouse o ambos), y siempre encima el modelo semántico como acuerdo compartido. Si ese acuerdo es débil, cualquier herramienta que consuma los datos, incluida la IA, hereda esa debilidad.
Entonces, ¿por dónde empiezo?
Un punto de partida concreto:
- Lista las decisiones de negocio que dependen de tus datos.
- Identifica quién los consulta y con qué herramienta.
- Clasifica tus fuentes por estructura y variedad.
- Estima si el proyecto se queda chico o va a escalar por áreas.
- Con eso, elige la puerta de entrada (lakehouse, warehouse o ambos) y define desde el inicio propietarios y señales de confianza.
Si quieres ver cómo se aplica este criterio a una empresa real, con arquitectura, gobierno y modelo semántico trabajando juntos, mira la demo gratuita y evalúa con claridad cuál es el mejor punto de partida para tu caso.
Preguntas relacionadas
¿Cuál es la diferencia básica entre un lakehouse y un warehouse en Microsoft Fabric?
El lakehouse guarda los datos como archivos en el lago con una capa de tabla encima y es fuerte para ingestar y transformar datos variados. El warehouse ofrece una experiencia relacional con SQL sobre tablas modeladas. En Fabric ambos viven sobre OneLake, así que comparten la misma base de datos.
¿Puedo usar lakehouse y warehouse al mismo tiempo?
Sí, y es común. Muchas soluciones usan el lakehouse para preparar y curar (capas Bronze, Silver y Gold de la arquitectura medallion) y el warehouse para exponer lo curado a consultas analíticas con SQL. Al compartir OneLake, no se generan silos duplicados.
¿Necesito una arquitectura compleja desde el primer día?
No. Si el proyecto es pequeño, conviene simplificar: un entorno y pocas capas. Si va a escalar, se define desde el inicio la separación por entorno, capa o dominio y se registran propietarios, descripciones, sensibilidad y señales de confianza.
¿Qué papel juega OneLake Catalog en esta decisión?
OneLake Catalog reúne descubrimiento, gobierno y seguridad. Permite explorar los elementos, revisar su confianza y linaje, gobernar los activos y centralizar el acceso. Elegir la topología sin definir gobierno deja la solución a medias.
¿Por qué importa el modelo semántico si ya elegí la arquitectura?
Porque ni el lakehouse ni el warehouse definen qué significan tus métricas. El modelo semántico es el acuerdo compartido que asegura que un número quiera decir lo mismo en Excel, Power BI o una IA. Primero el criterio y las métricas, después la topología, y el modelo semántico siempre encima.