Data warehouse vs data lake: guia de decision para 2025

La pregunta que todos hacen mal

“Deberiamos usar un data warehouse o un data lake?” Es la pregunta equivocada. La pregunta correcta es: que cargas de trabajo tenemos, que latencia necesitamos, y cuanto estamos dispuestos a pagar?

La respuesta casi nunca es “uno u otro”. La respuesta suele ser “ambos, con roles claros”. Pero para llegar ahi, primero hay que entender que es cada cosa sin la capa de marketing que cada vendor le pone encima.

Tres arquitecturas, sin humo

Data warehouse. Almacen de datos estructurados, optimizado para consultas analiticas. 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 que sirve: dashboards de negocio, reporting financiero, KPIs operativos, cualquier consulta SQL que necesite respuesta rapida sobre datos estructurados.

Para que no sirve: almacenar datos en bruto, procesar logs a gran escala, entrenar modelos de machine learning, almacenar imagenes/video/audio.

Data lake. Almacen de datos en cualquier formato (CSV, JSON, Parquet, imagenes, 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 que sirve: almacenamiento masivo a bajo coste, datos semiestructurados, exploración de datos, feature engineering para ML, archivo historico.

Para que no sirve: consultas interactivas rapidas, dashboards con refresh de 5 segundos, usuarios de negocio que necesitan respuestas inmediatas.

Data lakehouse. La convergencia. Un data lake con una capa de gestion que le aporta las garantias de un warehouse: transacciones ACID, schema enforcement, time travel, indices. Tecnologias como Apache Iceberg, Delta Lake, y Apache Hudi convierten un data lake en algo que se comporta como un warehouse para cargas analiticas, 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 analiticas con usuarios de negocio, un warehouse dedicado sigue dando mejor rendimiento y mejor experiencia de usuario.

Framework de decision

En lugar de elegir por instinto o por lo que use tu competencia, respondemos cuatro preguntas.

Pregunta 1: Que 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 seria complementario para logs, documentos, y datos de entrenamiento de ML.

Si tienes una mezcla significativa de datos estructurados y no estructurados (IoT, imagenes, logs de aplicacion, datos de sensores), el data lake es la base. Puedes poner un warehouse encima para las consultas analiticas, o usar un lakehouse.

Un caso que hemos visto repetido: empresas que meten datos no estructurados en un warehouse porque es lo unico que tienen. El resultado es una factura de Snowflake de 8,000 euros/mes cuando el 60% de los datos podria estar en S3 por 200 euros/mes. Costoso e innecesario.

Pregunta 2: Quien va a consultar los datos?

Usuarios de negocio (directores, controllers, marketing) necesitan SQL estandar, 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 tecnicos que no necesitan la abstraccion del warehouse.

Si tienes ambos grupos (y casi todas las empresas medianas los tienen), la arquitectura mas eficiente es un lake como base con una capa warehouse materializada para las consultas de negocio.

Pregunta 3: Que latencia necesitas?

Dashboards operativos con refresh de 5-10 segundos: warehouse. No hay alternativa real.

Informes diarios o semanales: lake con batch processing. Mas barato, igual de efectivo.

Consultas exploratorias ad-hoc: lake con un motor de query (Athena, Trino). Latencia de 5-30 segundos, suficiente para exploracion.

Modelos de ML que necesitan acceso a historico completo: lake. El warehouse no es el lugar para servir features de entrenamiento a Spark.

Pregunta 4: Cuanto puedes gastar?

Aqui es donde la decision se vuelve concreta. Comparativa de costes para un volumen tipico de empresa mediana (5 TB de datos, 100 consultas/dia):

Componente	Warehouse (Snowflake)	Lake (S3 + Athena)	Lakehouse (S3 + Iceberg + Trino)
Almacenamiento	~200 EUR/mes	~115 EUR/mes	~115 EUR/mes
Computo de consultas	~800 EUR/mes	~150 EUR/mes	~300 EUR/mes
Ingestion/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 mas 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 mas economico.

El lakehouse ocupa el punto medio: mas caro que un lake puro, pero con las garantias transaccionales y la experiencia de consulta que un lake crudo no ofrece.

Nuestra recomendacion por perfil

Empresa mediana con analytics clasicos (reporting, dashboards, KPIs): Warehouse. BigQuery si ya estas en GCP, Snowflake si eres multi-cloud, Redshift si estas 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 tecnico 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 produccion: Lake como base, warehouse como capa de servicio. La mayoria 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 rapida.

Empresa pequena 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 basicas. A veces la mejor arquitectura es la mas sencilla.

El error mas comun

El error que vemos con mas frecuencia no es elegir la tecnologia equivocada. Es no definir la gobernanza de datos antes de elegir la arquitectura. Sin un catalogo de datos, sin politicas 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 que hay, que es fiable, y que esta obsoleto.

La arquitectura de datos no es un problema de tecnologia. Es un problema de organizacion con una solucion tecnica. Y la solucion tecnica correcta depende de tu organizacion, no de lo que diga un blog de un vendor.

Para entender como 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 diagnostico: que datos tienes, donde estan, quien los usa, y para que. La tecnologia viene despues.