Durante mucho tiempo, las empresas eligieron entre dos opciones para gestionar sus datos: el data warehouse, estructurado y rápido para análisis pero caro y rígido, o el data lake, flexible y económico pero con problemas crónicos de gobernanza y calidad.
El lakehouse llegó para no tener que elegir. Y en 2026, su relevancia va más allá de resolver esa dicotomía: es la arquitectura sobre la que se sostienen los modelos de IA, los agentes autónomos y cualquier sistema que necesite datos fiables para tomar decisiones en tiempo real.
El problema que el lakehouse vino a resolver
El data warehouse fue durante décadas la arquitectura de referencia para análisis empresarial. Funcionaba bien para datos estructurados, consultas SQL y reporting de negocio. El problema llegó cuando las organizaciones empezaron a manejar volúmenes masivos de datos no estructurados (logs, imágenes, texto, datos de sensores) que los warehouses no podían absorber bien sin disparar los costes.
Los data lakes prometieron resolver eso: almacenamiento barato, sin esquema fijo, capaz de guardar cualquier tipo de dato. En teoría, era la solución. En la práctica, la mayoría de equipos que los implementaron sin la disciplina adecuada acabaron con lo que en el sector se conoce como un data swamp: millones de archivos sin linaje documentado, transformaciones duplicadas y dashboards que nadie se fiaba de consultar.
El lakehouse emerge como arquitectura que combina la flexibilidad del lake con las garantías transaccionales y el rendimiento del warehouse, usando formatos abiertos como Delta Lake, Apache Iceberg o Apache Hudi. No es una versión mejorada de ninguno de los dos: es una tercera arquitectura que toma lo mejor de cada una y resuelve lo que el otro no puede.
¿Qué es un data lakehouse?
Un data lakehouse es una arquitectura de datos moderna que crea una plataforma única combinando las capacidades de almacenamiento de datos sin procesar de los data lakes con la estructura organizada de los almacenes de datos. Sobre esa base, añade tres capacidades que ninguno de los dos tenía por separado: transacciones ACID, gestión de metadatos a escala y soporte nativo para cargas de trabajo de machine learning junto a las analíticas tradicionales.
Las transacciones ACID son el cambio más importante. Garantizan que las operaciones de lectura y escritura sobre los datos son consistentes aunque haya varios procesos trabajando sobre la misma tabla en paralelo. Para una empresa que actualiza su lakehouse con datos de ventas en tiempo real mientras un analista consulta esos mismos datos para un informe, eso no es un detalle técnico: es la diferencia entre un sistema fiable y uno que genera resultados distintos según cuándo se consulte.
Databricks popularizó el concepto en 2019 con la publicación de un paper de investigación conjunto con la Universidad de California en Berkeley y la Universidad de Stanford. El mercado global de data lakehouse está experimentando un crecimiento exponencial: se proyecta que alcanzará los 14.000 millones de dólares en 2025 y que crecerá a una tasa compuesta del 23,2% hasta aproximadamente 112.000 millones en 2035.
Arquitectura Medallion: cómo se organiza el dato dentro del lakehouse
Tener un lakehouse no garantiza que los datos estén en buen estado. La arquitectura que determina cómo los datos se refinan progresivamente dentro del lakehouse es la arquitectura Medallion, propuesta originalmente por Databricks y adoptada hoy como estándar en casi cualquier implementación seria.
La arquitectura Medallion organiza el lakehouse en tres capas progresivas (Bronze, Silver y Gold) donde cada capa aplica un estándar de calidad más alto sobre los mismos datos subyacentes. No es solo una convención de nomenclatura: es un contrato de equipo sobre quién es responsable de la calidad del dato en cada etapa y qué garantías tienen los consumidores de datos aguas abajo.
Capa Bronze: datos en bruto
La capa Bronze almacena los datos tal como llegan de las fuentes de origen, sin transformaciones, con metadatos adicionales que registran la procedencia y el momento de carga. El objetivo no es tener datos limpios: es tener un registro histórico inmutable de todo lo que ha entrado en el sistema. Eso permite reprocesar desde el origen si en el futuro se detecta un error en una transformación posterior, sin tener que volver a las fuentes.
Capa Silver: datos limpios y conformados
En Silver, los datos se limpian, se deduplican y se normalizan para crear lo que se puede llamar una vista empresarial coherente de las entidades de negocio. Un cliente que aparece con tres identificadores distintos en tres sistemas fuente distintos se consolida aquí en un único registro. Los esquemas se estandarizan. Las validaciones de calidad se aplican. El resultado es un conjunto de datos en el que múltiples equipos pueden confiar para análisis ad hoc, reporting avanzado y proyectos de machine learning.
Capa Gold: datos listos para el negocio
Gold contiene los datos agregados, enriquecidos y preparados para consumo directo: dashboards de BI, modelos de ML en producción, informes ejecutivos, APIs que sirven datos a aplicaciones. Bronze es crudo, Silver es refinado, Gold es curado. Juntos, convierten el caos en claridad. En la práctica, cada tabla Gold está diseñada para un consumidor específico, con la granularidad, las métricas y el formato que ese consumidor necesita, sin que tenga que hacer transformaciones adicionales para usarlos.
Los componentes técnicos que lo hacen funcionar
Un lakehouse no es un producto: es una arquitectura. Lo que la hace funcionar en la práctica es la combinación de varias tecnologías que trabajan juntas.
Los formatos de tabla abiertos son la capa de almacenamiento. Delta Lake (desarrollado por Databricks y open source desde 2019) , Apache Iceberg y Apache Hudi son los tres estándares principales. Estos formatos permiten que diferentes motores y plataformas trabajen sobre los mismos datos, sin depender de un único proveedor.
El catálogo de metadatos unificado es lo que convierte el almacenamiento en un sistema gobernado. Unity Catalog de Databricks es el referente actual: gestiona permisos, linaje de datos y gobierno de modelos de ML en una sola capa. Unity Catalog lidera con una adopción superior al 40% en empresas para gobernar tablas en formatos abiertos.
Los motores de consulta permiten ejecutar SQL de alto rendimiento directamente sobre los archivos en el object storage, sin necesidad de mover los datos a un sistema separado. Motores como Trino, Presto, DuckDB y Apache Datafusion permiten consultar data lakes sin mover datos, lo que reduce la dependencia de data warehouses propietarios y habilita arquitecturas de query federation donde una consulta SQL puede tocar simultáneamente el warehouse, el lake, bases operacionales y APIs SaaS.
Lakehouse vs. data warehouse vs. data lake: cuándo usar cada uno
La decisión no es siempre a favor del lakehouse. Hay contextos donde el data warehouse sigue siendo la opción correcta y otros donde la flexibilidad de un data lake puro es suficiente.
- El data warehouse sigue siendo la opción adecuada cuando los datos son mayoritariamente estructurados, el equipo de analistas trabaja exclusivamente con SQL, el volumen de datos es manejable y no hay cargas de trabajo de ML ni de datos no estructurados en el horizonte. Es más simple de operar y más maduro en términos de herramientas de BI.
- El data lake sin capas adicionales tiene sentido en fases de exploración temprana, cuando el equipo todavía no sabe qué preguntas va a hacer a los datos y necesita acumular información sin imponer estructura. En cuanto la organización quiere usar esos datos para tomar decisiones o entrenar modelos, la ausencia de gobernanza empieza a ser un problema.
- El lakehouse es la opción correcta cuando la organización maneja datos de múltiples tipos y fuentes, cuando hay tanto analistas de negocio como data scientists trabajando sobre los mismos datos, cuando hay modelos de ML en producción o en proyecto, y cuando la gobernanza, la trazabilidad y el control de costes son requisitos que no se pueden sacrificar.
El lakehouse como base para la IA agéntica
Aquí es donde la conversación sobre lakehouse cambia en 2026. Durante años, el debate giró alrededor de analítica y BI. Eso ya está resuelto. El debate que importa ahora es otro: qué arquitectura de datos necesita una organización para que sus sistemas de IA (modelos generativos, agentes autónomos, sistemas de decisión automatizada) funcionen con fiabilidad y con garantías de auditoría.
La respuesta es el lakehouse, pero en una versión más evolucionada de lo que fue en 2019. El lakehouse moderno evoluciona del almacenamiento pasivo a una capa de inteligencia activa que contextualiza la información, hace cumplir políticas, audita decisiones y preserva la trazabilidad. Con esta base, las empresas pueden construir flujos de trabajo verdaderamente autónomos que recuerden, se adapten y se autocorrijan, las capacidades que definirán el ROI de la IA en los próximos años.
Un agente de IA que opera sobre datos del lakehouse sabe de dónde vienen esos datos, qué transformaciones han sufrido, qué versión está consumiendo y qué permisos tiene para acceder a qué tablas. Eso no es un lujo: es la condición que hace que el output del agente sea auditable y que la organización pueda asumir la responsabilidad de las decisiones que toma. Los agentes de IA permiten a los analistas de datos traducir agregaciones de comportamiento complejas directamente en estrategias comerciales prácticas, accediendo de forma segura a los datos estructurados y gobernados del lakehouse a través de protocolos estándares.
Cómo trabajmos en BertIA con arquitecturas lakehouse
En BertIA, el lakehouse es la base de casi cualquier proyecto de datos en entornos Azure. No porque sea la tecnología más de moda, sino porque es la que permite escalar sin perder el control sobre la calidad y el gobierno de los datos, dos condiciones que en los diferentes sectores donde trabajamos, no son opcionales.
En diferentes casos, la implementación estándar parte de Databricks como plataforma central, con Delta Lake como formato de tabla y Unity Catalog como capa de gobierno. La arquitectura Medallion se configura desde el inicio del proyecto: Bronze para la ingesta de todas las fuentes (ERP, CRM, sensores, datos externos), Silver para consolidar y limpiar, Gold para los casos de uso específicos de negocio. Esa estructura es la que permite que los modelos de machine learning y los sistemas de MLOps que gestionan su ciclo de vida tengan siempre acceso a datos con linaje documentado y calidad verificada.
Lo que cambia en los proyectos más recientes es la capa de IA agéntica encima del lakehouse. Los agentes necesitan contexto fiable para producir decisiones correctas: el lakehouse bien construido es precisamente eso. Cuando un agente consulta el data warehouse o accede a tablas Gold para tomar una decisión automatizada, la trazabilidad de Unity Catalog registra qué datos consumió, cuándo y qué versión. Si esa decisión se cuestiona en una auditoría, la respuesta está disponible sin reconstruir nada.
Conclusión
El lakehouse resolvió el dilema entre flexibilidad y gobernanza que durante años obligó a las empresas a elegir entre data lake y data warehouse. En 2026, su relevancia va más allá: es la infraestructura que hace posible que los sistemas de IA y los agentes autónomos operen con datos fiables, trazables y gobernados. Las organizaciones que construyan su lakehouse con rigor hoy están construyendo también la base sobre la que van a correr sus iniciativas de IA durante los próximos años.
Si estás evaluando cómo modernizar tu arquitectura de datos o cómo hacer que tu plataforma actual soporte las cargas de trabajo de IA que tienes en proyecto, habla con nuestro equipo para analizar tu caso concreto.
