Data Warehouse, Data Lake o Data Lakehouse: cuál le corresponde a tu empresa

Tres arquitecturas que suenan parecido pero resuelven problemas distintos. Una guía honesta para entender cuál necesita tu empresa según escala, equipo y volumen.

Un director de tecnología en una empresa de manufactura de 200 empleados nos contactó hace unos meses con una pregunta directa: “¿Necesitamos un data lake o un data warehouse? El equipo de consultoría nos recomendó los dos, pero el presupuesto no alcanza para ambos”.

La respuesta fue: ninguno de los dos. Lo que necesitaban era un data lakehouse. Pero para llegar a esa conclusión, hay que entender qué resuelve cada arquitectura, para qué empresa fue diseñada, y en qué momento tiene sentido cada una.

Data Warehouse, Data Lake y Data Lakehouse son tres términos que aparecen en todas las conversaciones sobre modernización de datos. A veces se usan como sinónimos. A veces se confunden. Y casi siempre terminan generando decisiones de arquitectura que cuestan más de lo necesario o resuelven menos de lo esperado.

Este post es la guía práctica para distinguirlos y no terminar pagando por una arquitectura que no corresponde a la escala y necesidades reales de tu empresa.

¿Qué es un Data Warehouse y para quién fue diseñado?

Un Data Warehouse organiza los datos antes de almacenarlos. Todo tiene un esquema definido: columnas con tipos específicos, relaciones entre tablas, reglas de validación que se aplican al momento de ingresar los datos. En el mundo de bases de datos esto se llama “schema-on-write”: la estructura existe antes de escribir.

El resultado es un sistema optimizado para consultas predecibles. Los reportes que se ejecutan todos los lunes, los dashboards que finanzas revisa cada día, los números de cierre mensual — todo funciona muy rápido en un Data Warehouse porque el esquema es rígido y las consultas son conocidas de antemano.

El Data Warehouse nació en los años 80 y 90, cuando las grandes empresas (bancos, retailers, aseguradoras) necesitaban consolidar datos operacionales de múltiples sistemas transaccionales para generar reportes de gestión. Fue diseñado para empresas con datos estructurados, procesos bien definidos, y equipos de BI que saben exactamente qué preguntas le hacen a los datos.

Cuándo tiene sentido:

• Sabes exactamente qué preguntas le vas a hacer a tus datos hoy y en los próximos dos años
• Tu equipo de BI trabaja principalmente con dashboards y reportes fijos
• Los datos llegan limpios y estructurados desde los sistemas fuente
• La velocidad de consulta para muchos usuarios simultáneos es crítica

Cuándo no tiene sentido:

• Tus datos vienen de muchas fuentes con formatos heterogéneos
• Necesitas explorar y descubrir qué hay en los datos antes de definir los reportes
• Quieres alimentar modelos de machine learning sin levantar otro sistema
• El costo de licencias enterprise (Snowflake, Redshift, BigQuery, Synapse) no está justificado para tu escala

El problema real del Data Warehouse: la rigidez del esquema. Cuando el negocio cambia —y siempre cambia— modificar el esquema en un Data Warehouse es costoso. Requiere planificación, trabajo de ingeniería, y en muchos sistemas, migraciones que implican downtime. Cada cambio en el negocio se convierte en un proyecto técnico.

¿Qué es un Data Lake y por qué fracasa tan seguido?

Un Data Lake almacena todo tal como llega: estructurado, semiestructurado, sin estructura. JSONs de APIs, CSVs de sistemas legacy, archivos Parquet de pipelines modernos, logs de servidores — todo entra sin transformar. La estructura se define al momento de leer (“schema-on-read”), no al escribir.

La promesa es atractiva: un repositorio centralizado de todos los datos de la empresa, listos para análisis cuando se necesiten. Conservas el histórico completo, en el formato original, sin tener que definir de antemano qué vas a hacer con eso.

El problema es que sin gobernanza, el Data Lake se convierte en un data swamp: un repositorio caótico donde nadie sabe qué hay, dónde está, ni si el dato es confiable. Es uno de los fracasos más documentados en proyectos de datos de los últimos diez años. Gartner estimó en su momento que más del 60% de los proyectos de Data Lake no entregan valor medible.

El Data Lake surgió en el ecosistema de Hadoop/MapReduce de las grandes empresas de tecnología (Google, Facebook, LinkedIn): compañías con volúmenes de petabytes, equipos de data engineering de decenas de personas, y la capacidad de construir gobernanza personalizada sobre el lago.

Cuándo tiene sentido:

• Manejas volúmenes de datos muy grandes (terabytes a petabytes)
• Tu equipo de data science necesita acceso a datos crudos para experimentar
• Tienes datos de fuentes muy heterogéneas que no pueden normalizarse al ingresar
• Necesitas conservar histórico completo sin saber de antemano cómo lo vas a usar

El riesgo real: un Data Lake sin el equipo y los procesos para gobernarlo es, en la práctica, peor que no tener nada. Los datos están, pero nadie sabe cómo usarlos. Para la mayoría de las empresas medianas, implementar un Data Lake puro significa asumir una deuda técnica y organizacional que no tienen capacidad de pagar.

¿Qué es un Data Lakehouse y por qué es la arquitectura correcta para la mayoría de las empresas medianas?

El Data Lakehouse surgió exactamente del problema del Data Lake: tomó la flexibilidad y el bajo costo del almacenamiento en archivos abiertos, y le añadió la estructura, la governance y la velocidad de consulta del Data Warehouse.

En términos técnicos: los datos se almacenan en formatos abiertos (principalmente Parquet) en almacenamiento de objetos (S3, GCS, Azure Blob). Sobre eso, una capa de procesamiento SQL (DuckDB, Spark, Trino) ejecuta las consultas. Las transformaciones están versionadas en dbt y la orquestación corre en Dagster o Airflow.

Lo que ganas:

• Costo de almacenamiento bajo — Parquet en disco, sin licencias por GB
• Consultas SQL rápidas sin servidor de base de datos pesado
• Soporte nativo para ML — Parquet es el formato que usan pandas, sklearn y PyTorch
• Datos crudos conservados y datos procesados accesibles al mismo tiempo
• Schema enforcement sin la rigidez de un warehouse tradicional
• Sin vendor lock-in — los datos están en un estándar abierto que leen todas las herramientas

Cuándo corresponde:

• Múltiples fuentes de datos con formatos distintos
• Necesitas reportes de negocio y análisis exploratorio al mismo tiempo
• Quieres dejar la puerta abierta a ML sin levantar otro sistema
• Equipo técnico pequeño que necesita mantener todo sin fricción operativa

Comparación directa: qué resuelve cada arquitectura

	Data Warehouse	Data Lake	Data Lakehouse
Costo de licencias	Alto (Snowflake, Redshift)	Bajo (cloud storage)	Bajo (open-source + storage)
Setup inicial	Semanas	Semanas-meses	Días-semanas
Flexibilidad de esquema	Baja	Alta	Alta
Velocidad de consulta	Alta	Baja sin capa SQL	Alta
Soporte para ML	Limitado	Nativo (datos crudos)	Nativo (Parquet)
Vendor lock-in	Alto	Medio	Bajo (estándares abiertos)
Usuarios concurrentes	100+	Requiere infraestructura adicional	10-200
Equipo mínimo recomendado	BI + DBA	Data engineering grande	1-2 data engineers

Un ejemplo concreto: empresa de distribución, 180 empleados

Una empresa de distribución de insumos industriales con operaciones en tres países tenía el problema clásico: datos en SAP (finanzas), Salesforce (ventas), un sistema propio de logística desarrollado en PHP, y Excel en todos lados.

Evaluaron tres caminos:

Con Snowflake: precio estimado ~$1.500/mes de entrada. Requería normalizar los datos al ingresar, lo que implicaba semanas de trabajo de modelado antes de ver el primer resultado. Y con los cambios frecuentes en la estructura de datos de SAP, el mantenimiento del esquema iba a ser trabajo continuo e impredecible.

Con un Data Lake puro: precio bajo en storage, pero sin un equipo de data engineering dedicado para construir la gobernanza, el riesgo de terminar con un data swamp era real y alto. Y sin una capa SQL encima, los reportes de negocio requerían scripts de Python que nadie del área de finanzas podía ejecutar sola.

Con Data Lakehouse (DuckDB + Parquet + dbt): precio estimado ~$80/mes en storage S3. Los datos crudos de las tres fuentes se preservan en Parquet sin transformar. dbt construye las transformaciones en SQL estándar, versionado en Git. DuckDB ejecuta las consultas en segundos sobre 200GB de datos.

Eligieron el Lakehouse. En tres semanas tenían los primeros reportes funcionando. En seis semanas, el cierre mensual pasó de cinco días a cuatro horas. El costo total de implementación se recuperó en el segundo mes de operación con el ahorro de tiempo del equipo de finanzas.

¿Cómo migrar de un Data Warehouse a un Lakehouse?

La pregunta más frecuente que llega después de leer comparaciones como esta: “Estamos en Snowflake y queremos salir. ¿Qué tan difícil es?”

La respuesta depende del nivel de lock-in acumulado, pero en general el proceso tiene tres fases:

Fase 1 — Exportar y replicar (semanas 1-2): exportar todas las tablas de Snowflake a Parquet en S3. No es complejo técnicamente, pero requiere validar que la exportación sea completa y sin pérdida de tipos de datos.

Fase 2 — Portar las transformaciones a dbt (semanas 2-6): las transformaciones que estaban en procedimientos almacenados o en el dialecto SQL propietario del warehouse hay que portarlas a SQL estándar en dbt. Cuanto más funcionalidades propietarias usaban (Snowpipe, Streams, Tasks), más trabajo hay en esta fase.

Fase 3 — Reconectar las herramientas de BI (semanas 4-8): los dashboards de Power BI, Tableau o Metabase necesitan reconectarse al nuevo motor de consulta. En la mayoría de los casos es cambiar el conector y las credenciales, sin rehacer los dashboards.

Para la mayoría de las empresas medianas, la migración toma entre 6 y 12 semanas. El ahorro anual en licencias suele pagar el costo de migración en los primeros 3-4 meses.

¿Cómo elegir sin equivocarse?

Una pregunta simple para orientarte:

¿Ya sabes exactamente qué preguntas le vas a hacer a tus datos, o todavía estás descubriendo qué tienes?

Si sabes exactamente qué necesitas y los datos llegan limpios → un Data Warehouse puede ser la respuesta correcta.

Si estás ordenando el caos, cruzando fuentes heterogéneas, y necesitas flexibilidad para crecer → un Data Lakehouse es el punto de partida correcto.

Si eres Netflix o Uber con un equipo de 50 ingenieros de datos → tienes otros problemas que este post no cubre.

El error más común: elegir la arquitectura antes de entender el problema. La mayoría de las implementaciones fallidas no fallan por tecnología — fallan porque alguien eligió una arquitectura para el negocio que quiere ser, no para el que es hoy.

La implementación liviana que nadie menciona

El Lakehouse no requiere plataformas enterprise ni presupuesto de corporación. Para la mayoría de las empresas medianas, la arquitectura correcta es:

• DuckDB como motor de consulta SQL columnar — analiza terabytes sin infraestructura costosa
• Parquet como formato de almacenamiento — portable, eficiente, compatible con cualquier herramienta de ML
• dbt para transformaciones versionadas y documentadas en SQL estándar
• Dagster para automatizar cuándo y cómo corre cada paso del pipeline

La arquitectura tiene tres capas: datos crudos tal como llegan (Bronze), datos limpios y validados (Silver), datos listos para análisis (Gold). Sin servidores de base de datos pesados. Sin licencias por GB. Sin vendor lock-in.

Puedes leer la explicación completa de esta arquitectura en medallion architecture explicada.

Preguntas frecuentes

¿Un Data Lakehouse es más difícil de mantener que Snowflake?

Snowflake simplifica la operación porque no hay infraestructura que gestionar, pero a cambio de un costo mensual significativo y vendor lock-in progresivo. Un Lakehouse bien configurado requiere conocimiento técnico inicial —conectar las fuentes, modelar las transformaciones, configurar el pipeline— pero el mantenimiento diario es mínimo. Para equipos con al menos un perfil técnico, el trade-off está a favor del Lakehouse.

¿Puedo empezar con un Lakehouse y escalar después si crezco?

Sí, y es el camino recomendado. Un Lakehouse en DuckDB + Parquet puede manejar cómodamente hasta 1-5 terabytes en un solo servidor. Si en el futuro necesitas más escala o más usuarios concurrentes, migrar a Spark o a un warehouse administrado es mucho más fácil cuando los datos ya están en Parquet que cuando están en un formato propietario.

¿Cuánto cuesta implementar un Lakehouse desde cero?

La implementación tiene un costo inicial de ingeniería: conectar las fuentes de datos, modelar las transformaciones, configurar el pipeline. El costo recurrente es el storage: para empresas de 50-500 empleados, típicamente entre $20 y $150/mes en S3, dependiendo del volumen. Sin costo de licencias de software.

¿El Data Lakehouse reemplaza a Excel?

No. Excel sigue siendo útil para análisis ad hoc, trabajo individual y presentaciones. Lo que el Lakehouse reemplaza son los reportes críticos que hoy viven en planillas compartidas, el cruce manual de datos entre sistemas, y los cierres mensuales que dependen de que una persona específica ejecute macros en el orden correcto.

¿Necesito un data engineer a tiempo completo para mantener un Lakehouse?

No necesariamente. Un Lakehouse bien configurado puede ser mantenido por alguien con conocimientos de SQL y algo de Python. El punto clave es que las transformaciones están en dbt (SQL estándar, versionado, documentado) y el pipeline en Dagster (con logs claros y alertas configurables). El equipo de negocio puede trabajar con los datos de la capa Gold sin tocar la infraestructura.

---

Si este post te fue útil, lee también qué es exactamente un data lake y por qué el vendor lock-in es el costo que nadie calcula.

Agenda una llamada. En 30 minutos te decimos qué arquitectura tiene sentido para tu empresa hoy.