Lakehouse vs Data Warehouse: guía de decisión para equipos técnicos y de negocio

Si llevas un rato evaluando arquitecturas de datos, probablemente ya viviste esta escena: dos proveedores te presentan algo que suena idéntico con nombres distintos. Uno dice "warehouse moderno", el otro dice "lakehouse", los dos usan la palabra escalable seis veces, y tú sales de la junta sin saber si el lakehouse es una evolución del warehouse, un reemplazo o el mismo concepto con mejor marketing.

Este post es para aclarar eso. No vamos a coronar un ganador, porque no hay uno: son dos arquitecturas con supuestos distintos sobre cómo se usan los datos, y cada una es mejor en escenarios diferentes. Lo que sí vas a encontrar es qué hace cada una, en qué se notan las diferencias cuando ya estás operando, dónde se esconden los costos que nadie pone en la propuesta, y cuatro perfiles concretos para que ubiques cuál se parece más a tu situación.

Qué es un data warehouse (y por qué lleva treinta años funcionando)

Un data warehouse es un repositorio diseñado para analizar datos estructurados. La palabra clave es diseñado: antes de que un dato entre, alguien definió el esquema que debe cumplir. Tablas, columnas, tipos, relaciones. Si el dato no encaja, no entra.

Esa disciplina en la puerta de entrada es justamente su ventaja. Todo lo que está adentro es consistente, consultable con SQL y confiable para reportar. Por eso los warehouses son la columna vertebral del BI corporativo: cuando finanzas presenta el cierre al consejo, nadie quiere sorpresas de formato.

Piénsalo como un almacén con estantería etiquetada y un inventario que se revisa en la recepción. Encontrar cualquier cosa es rápido. El costo de ese orden es que meter algo nuevo requiere trabajo previo.

Y conviene decirlo sin rodeos, porque muchos artículos lo tratan como tecnología de museo: el data warehouse no está obsoleto. Para consulta analítica sobre datos estructurados con lógica de negocio estable sigue siendo la opción más eficiente y la que tu equipo ya sabe usar.

Qué es un data lakehouse (y qué vino a resolver)

La historia corta tiene tres capítulos.

Primero fueron los warehouses. Funcionaban bien hasta que llegaron datos que no encajaban en tablas: logs, eventos, JSON, texto, imágenes, telemetría. Meter eso en un esquema rígido era caro o imposible.

Entonces aparecieron los data lakes: almacenamiento de objetos barato donde puedes depositar cualquier archivo sin definir estructura. Resolvió el problema del formato y creó otro. Sin catálogo, sin control de calidad y sin nadie a cargo, muchos lagos se convirtieron en pantanos: terabytes de archivos que nadie sabe qué contienen ni si se pueden usar para decidir algo. El cajón de los cables de tu casa, pero facturado por mes.

El lakehouse es el tercer capítulo: mantener el almacenamiento barato y flexible del lago, pero ponerle encima una capa de metadatos y transacciones que le devuelve el orden del warehouse.

Eso se logra con formatos de tabla abiertos —Delta Lake, Apache Iceberg y Apache Hudi son los tres nombres que vas a escuchar— que agregan transacciones confiables, versiones históricas y control de esquema sobre archivos que siguen viviendo en almacenamiento de objetos.

En la analogía: es la bodega grande donde cabe todo, pero con inventario, catálogo y bitácora de quién movió qué.

Comparación rápida

	Data warehouse	Data lakehouse
Tipos de dato	Estructurados	Estructurados, semi y no estructurados
Esquema	Definido antes de cargar	Flexible, se valida por capas
Cargas de trabajo	BI, reporte, SQL analítico	BI, ML, streaming, ciencia de datos
Almacenamiento y cómputo	Generalmente acoplados	Separados
Formato	Propietario del proveedor	Abierto (Delta, Iceberg, Hudi)
Curva de aprendizaje	Baja para perfiles SQL	Media-alta, requiere ingeniería

La tabla sirve para orientarte, pero las decisiones no se toman con tablas. Las diferencias que de verdad pesan se sienten en la operación.

Las cinco diferencias que se notan en el día a día

1. Qué hace cada uno con lo que no viene en tablas

El warehouse necesita estructura previa. Si tu fuente es un archivo de eventos o un JSON anidado, hay que transformarlo antes de cargarlo, y esa transformación es código que alguien mantiene.

El lakehouse guarda el archivo tal cual y aplica estructura al leerlo. La consecuencia práctica: puedes empezar a almacenar antes de saber exactamente cómo vas a usar el dato. Muy útil cuando exploras, riesgoso cuando nadie documenta.

2. Almacenamiento y cómputo: juntos o separados

En un warehouse tradicional, capacidad de almacenamiento y capacidad de procesamiento suelen crecer juntas. Si necesitas guardar más histórico, pagas también por cómputo que quizá no usas.

En un lakehouse van por separado: el almacenamiento es barato y el cómputo se prende cuando hace falta. Esto se traduce en ahorro real si tus cargas son irregulares —procesamiento intenso unos días del mes, poco el resto— y en poco beneficio si tu uso es constante y predecible.

3. Formato abierto contra formato propietario

Un warehouse guarda los datos en su propio formato interno. Para leerlos, pasas por sus herramientas. Funciona bien mientras te quedes ahí.

Un lakehouse guarda archivos en formatos abiertos sobre almacenamiento que tú controlas. Distintos motores de procesamiento pueden leer las mismas tablas sin copiarlas. Eso importa menos por ideología y más por dos cosas concretas: cambiar de motor no implica migrar los datos, y puedes tener varias herramientas consultando una sola copia en lugar de mantener cuatro versiones de la misma verdad.

4. Qué pasa cuando tus fuentes cambian sin avisarte

Esta es la diferencia menos comentada y una de las más importantes.

En muchas organizaciones, los sistemas origen no dependen del equipo de datos. Un proveedor agrega una columna, cambia un tipo, renombra un campo. Nadie te avisa. En un esquema rígido, eso rompe la carga y alguien pasa el martes arreglándola.

Los formatos de tabla del lakehouse manejan evolución de esquema de forma nativa: puedes agregar campos sin reescribir la tabla ni romper lo que ya funciona. Si tu realidad son fuentes heterogéneas que se mueven por su cuenta, este punto solo puede pesar más que todos los demás juntos.

5. Quién puede trabajar con cada uno

Un warehouse lo explota un analista con SQL. Eso es mucha gente en cualquier organización.

Un lakehouse pide perfiles de ingeniería de datos para diseñar capas, mantener tablas, optimizar particiones y gobernar el catálogo. Se puede consultar con SQL, sí, pero alguien tuvo que construir y sostener las capas que lo hacen posible. Si ese alguien no existe, la arquitectura se degrada sola.

Hablemos de costos: la pregunta antes de la pregunta

Antes de comparar precios, vale la pena un diagnóstico honesto: ¿estás seguro de que tu problema está en la arquitectura?

Vemos cuatro cuellos de botella que se confunden entre sí:

• El sistema origen. Si tu ventana de extracción la define el ERP —cuánto tarda en entregarte los datos sin caerse—, el destino puede ser diez veces más rápido y tu proceso no se acorta.

• El modelado. Consultas lentas por un modelo mal diseñado siguen siendo lentas en cualquier plataforma.

• El gobierno. Si nadie sabe cuál de las tres tablas de ventas es la buena, ese es un problema de definiciones, no de motor.

• La adopción. Datos correctos que nadie consulta no se arreglan migrando.

Solo cuando el cuello de botella está de verdad en la capa analítica tiene sentido la comparación de costos. Y ahí el patrón general es bastante claro: el lakehouse abarata almacenamiento y cómputo, y encarece operación y talento. Los formatos abiertos requieren mantenimiento —compactación de archivos, gestión de versiones, optimización de tablas—, y los perfiles que lo hacen bien son más escasos y más caros que un buen analista de BI.

Dicho de otra forma: un warehouse bien gobernado suele salir más barato que un lakehouse mal implementado. El costo total incluye a las personas, no solo la factura de infraestructura.

Cómo decidir: cuatro situaciones reconocibles

Si casi todo tu consumo es BI y SQL

Analistas que hacen reportes, tableros y consultas sobre datos estructurados, con volúmenes predecibles y lógica de negocio estable. El warehouse gana. Añadir un lakehouse aquí es complejidad sin retorno.

Si tienes equipos de ML o ciencia de datos compitiendo por los mismos datos

Cuando hay modelos que necesitan datos crudos, históricos completos y features que el warehouse no expone, empieza a doler. El lakehouse resuelve exactamente ese conflicto: una sola copia que sirve tanto al tablero como al modelo.

Si tus fuentes son heterogéneas o se mueven sin tu control

Múltiples proveedores, sistemas heredados, distintos países con sus propias reglas, esquemas que cambian sin aviso. Aquí el lakehouse tiene una ventaja estructural: absorbe el desorden en lugar de romperse con él.

Si esperas convivencia

Es el escenario más común y no es un empate por indecisión. Es una asignación de roles: el warehouse para reporte financiero y BI gobernado, el lakehouse para ML, streaming y fuentes difíciles. La pregunta útil deja de ser cuál eliges y pasa a ser cómo los conectas sin duplicar la verdad.

Lo que suele salir mal

Ninguna de estas trampas es de tecnología. Todas son de ejecución.

• Migrar todo de golpe. Los proyectos que funcionan avanzan por dominios: un caso de negocio, en producción, con valor visible, y luego el siguiente.

• Diagnosticar mal el problema. Migrar un problema de modelado o de gobierno solamente lo muda de casa, con factura nueva.

• Elegir formato por moda. Delta, Iceberg y Hudi resuelven cosas parecidas de maneras distintas. El criterio no es cuál suena más moderno, sino cuál se integra mejor con las herramientas que ya usas y con los perfiles que ya tienes.

• No definir quién sostiene esto en el mes siete. Un lakehouse sin dueño de las tablas, la capa semántica y la calidad se convierte en el pantano del que estabas huyendo, solo que ahora con transacciones ACID.

• Subestimar la adopción. Nadie consulta lo que no entiende. Sin documentación, definiciones acordadas y acompañamiento al negocio, la plataforma queda técnicamente impecable y prácticamente vacía.

Algo que vemos con frecuencia: el punto donde se atoran los proyectos casi nunca es el mismo entre una organización y otra, y por eso un playbook genérico rinde menos que un acompañamiento que empiece por entender dónde estás parado. Si estás en ese momento, así trabajamos el lakehouse enablement en Arkon Data: sin reemplazar lo que ya funciona.

Lo que importa al decidir

El data warehouse sigue siendo la mejor herramienta para analizar datos estructurados con SQL. El lakehouse existe para los casos donde eso no alcanza: datos que no vienen en tablas, cargas de ML, fuentes que cambian solas. Y la mayoría de las organizaciones acaba con los dos, cada uno en lo suyo.

La decisión difícil, casi siempre, no es cuál de las dos arquitecturas eliges. Es tener claridad sobre dónde está tu problema real antes de mover nada.

Si quieres una lectura externa de tu arquitectura actual antes de decidir, podemos agendar una asesoría en datos sin compromiso.

Preguntas frecuentes sobre lakehouse y data warehouse

¿El lakehouse reemplaza al data warehouse? 

No necesariamente. Puede reemplazarlo cuando el warehouse era el único destino y sus limitaciones ya frenan casos de machine learning o fuentes no estructuradas. En la mayoría de los casos conviven, con el warehouse sirviendo BI y reporte gobernado.

¿Es más barato un lakehouse?

En almacenamiento y cómputo, normalmente sí. En operación y talento, normalmente no. El costo total depende de si tienes o no el equipo que lo mantenga.

¿Qué es un lakehouse en palabras simples?

Un lugar donde puedes guardar cualquier tipo de dato de forma económica, pero con el orden, el catálogo y la confiabilidad de un warehouse encima.

¿Puedo tener los dos?

Sí, y es lo bastante común. Lo importante es definir qué vive en cada uno y evitar mantener dos versiones de la misma métrica.

¿Cuánto tarda una migración?

Depende del alcance, pero el patrón sano es avanzar por dominios en ciclos cortos con valor en producción, en lugar de un proyecto único de muchos meses sin entregas intermedias.