Data warehouse vs data lake: guía de decisión para 2025
La pregunta que todos hacen mal
“Deberíamos usar un data warehouse o un data lake?” Es la pregunta equivocada. La pregunta correcta es: qué cargas de trabajo tenemos, qué latencia necesitamos, y cuánto estamos dispuestos a pagar?
La respuesta casi nunca es “uno u otro”. La respuesta suele ser “ambos, con roles claros”. Pero para llegar ahí, primero hay que entender qué es cada cosa sin la capa de marketing que cada vendor le pone encima.
Tres arquitecturas, sin humo
Data warehouse. Almacén de datos estructurados, optimizado para consultas analíticas. Los datos entran limpios, transformados, y con un esquema definido (schema-on-write). Latencia de consulta: subsegundo a minutos. Ejemplos: BigQuery, Snowflake, Redshift, Azure Synapse.
Para qué sirve: dashboards de negocio, reporting financiero, KPIs operativos, cualquier consulta SQL que necesite respuesta rápida sobre datos estructurados.
Para qué no sirve: almacenar datos en bruto, procesar logs a gran escala, entrenar modelos de machine learning, almacenar imágenes/video/audio.
Data lake. Almacén de datos en cualquier formato (CSV, JSON, Parquet, imágenes, logs), organizado en un sistema de archivos distribuido (S3, GCS, ADLS). Los datos entran tal cual, sin transformar. El esquema se aplica al leer, no al escribir (schema-on-read). Latencia de consulta: segundos a minutos (con motores como Athena, Presto, Spark SQL).
Para qué sirve: almacenamiento masivo a bajo coste, datos semiestructurados, exploración de datos, feature engineering para ML, archivo histórico.
Para qué no sirve: consultas interactivas rápidas, dashboards con refresh de 5 segundos, usuarios de negocio que necesitan respuestas inmediatas.
Data lakehouse. La convergencia. Un data lake con una capa de gestión que le aporta las garantías de un warehouse: transacciones ACID, schema enforcement, time travel, índices. Tecnologías como Apache Iceberg, Delta Lake, y Apache Hudi convierten un data lake en algo que se comporta como un warehouse para cargas analíticas, sin perder la flexibilidad del lake para cargas de ML y procesamiento de datos no estructurados.
El lakehouse es la tendencia dominante en 2025, pero no es la respuesta a todo. Para cargas puramente analíticas con usuarios de negocio, un warehouse dedicado sigue dando mejor rendimiento y mejor experiencia de usuario.
Framework de decisión
En lugar de elegir por instinto o por lo que use tu competencia, respondemos cuatro preguntas.
Pregunta 1: Qué tipo de datos tienes?
Si el 90% de tus datos son tablas estructuradas (transacciones, inventario, clientes, pedidos), un warehouse cubre tu necesidad principal. El data lake sería complementario para logs, documentos, y datos de entrenamiento de ML.
Si tienes una mezcla significativa de datos estructurados y no estructurados (IoT, imágenes, logs de aplicación, datos de sensores), el data lake es la base. Puedes poner un warehouse encima para las consultas analíticas, o usar un lakehouse.
Un caso que hemos visto repetido: empresas que meten datos no estructurados en un warehouse porque es lo único que tienen. El resultado es una factura de Snowflake de 8,000 euros/mes cuando el 60% de los datos podría estar en S3 por 200 euros/mes. Costoso e innecesario.
Pregunta 2: Quién va a consultar los datos?
Usuarios de negocio (directores, controllers, marketing) necesitan SQL estándar, baja latencia, y herramientas BI como Looker, Tableau, o Power BI. Para ellos, un warehouse es la mejor experiencia.
Data engineers y data scientists pueden trabajar con Spark, Python, y motores de query sobre el lake. Son usuarios técnicos que no necesitan la abstracción del warehouse.
Si tienes ambos grupos (y casi todas las empresas medianas los tienen), la arquitectura más eficiente es un lake como base con una capa warehouse materializada para las consultas de negocio.
Pregunta 3: Qué latencia necesitas?
Dashboards operativos con refresh de 5-10 segundos: warehouse. No hay alternativa real.
Informes diarios o semanales: lake con batch processing. Más barato, igual de efectivo.
Consultas exploratorias ad-hoc: lake con un motor de query (Athena, Trino). Latencia de 5-30 segundos, suficiente para exploración.
Modelos de ML que necesitan acceso a histórico completo: lake. El warehouse no es el lugar para servir features de entrenamiento a Spark.
Pregunta 4: Cuánto puedes gastar?
Aquí es donde la decisión se vuelve concreta. Comparativa de costes para un volumen típico de empresa mediana (5 TB de datos, 100 consultas/día):
| Componente | Warehouse (Snowflake) | Lake (S3 + Athena) | Lakehouse (S3 + Iceberg + Trino) |
|---|---|---|---|
| Almacenamiento | ~200 EUR/mes | ~115 EUR/mes | ~115 EUR/mes |
| Cómputo de consultas | ~800 EUR/mes | ~150 EUR/mes | ~300 EUR/mes |
| Ingestión/ETL | ~200 EUR/mes | ~100 EUR/mes | ~150 EUR/mes |
| Total estimado | ~1,200 EUR/mes | ~365 EUR/mes | ~565 EUR/mes |
El warehouse es 3x más caro que el lake para el mismo volumen de datos. Pero si tus usuarios de negocio necesitan consultas interactivas, la experiencia de usuario del warehouse justifica el sobrecoste. Si tus cargas son principalmente batch y ML, el lake es significativamente más económico.
El lakehouse ocupa el punto medio: más caro que un lake puro, pero con las garantías transaccionales y la experiencia de consulta que un lake crudo no ofrece.
Nuestra recomendación por perfil
Empresa mediana con analytics clásicos (reporting, dashboards, KPIs): Warehouse. BigQuery si ya estás en GCP, Snowflake si eres multi-cloud, Redshift si estás en AWS y quieres minimizar coste. No necesitas un lake salvo que tengas cargas de ML o datos no estructurados significativos.
Empresa con datos mixtos y equipo técnico fuerte: Lakehouse. S3/GCS como base, Iceberg o Delta Lake como formato de tabla, Trino o Spark SQL para consultas. Materialized views en el warehouse para los dashboards de negocio.
Startup data-intensive o empresa con ML en producción: Lake como base, warehouse como capa de servicio. La mayoría de los datos viven en el lake (barato, flexible). Los datos que necesitan servirse a dashboards se materializan en un warehouse o en una capa de serving rápida.
Empresa pequeña con menos de 1 TB de datos y sin equipo de datos dedicado: No necesitas ni lake ni lakehouse. Un PostgreSQL bien indexado con Metabase encima es suficiente para analytics básicas. A veces la mejor arquitectura es la más sencilla.
El error más común
El error que vemos con más frecuencia no es elegir la tecnología equivocada. Es no definir la gobernanza de datos antes de elegir la arquitectura. Sin un catálogo de datos, sin políticas de calidad, sin ownership claro de cada dataset, da igual si usas Snowflake o un data lake: vas a terminar con un “data swamp”, un lago de datos donde nadie sabe qué hay, qué es fiable, y qué está obsoleto.
La arquitectura de datos no es un problema de tecnología. Es un problema de organización con una solución técnica. Y la solución técnica correcta depende de tu organización, no de lo que diga un blog de un vendor.
Para entender cómo los datos fluyen hacia tu warehouse o lake, consulta nuestra comparativa ETL vs ELT. Si necesitas ayuda para definir tu arquitectura de datos, empezamos por el diagnóstico: qué datos tienes, dónde están, quién los usa, y para qué. La tecnología viene después.