Data lake vs data warehouse: diferencias y cuándo usar cada uno

Un data lake (lago de datos) es un repositorio que guarda grandes volúmenes de datos en su formato original, estructurados o no: tablas, ficheros de registro, documentos, imágenes o eventos. Un data warehouse (almacén de datos) guarda datos ya limpios, estructurados e integrados de varios sistemas, preparados para consultarlos con SQL y alimentar informes y cuadros de mando. Dicho de forma sencilla: el lago guarda todo por si acaso; el almacén guarda lo que ya sabes que vas a analizar.

El lakehouse es un enfoque intermedio que añade al lago capacidades propias del almacén, como transacciones fiables, control de versiones y consultas SQL eficientes. Las tres son arquitecturas pensadas para volúmenes y equipos de datos que la mayoría de pymes no tiene.

Porque es habitual que una empresa con datos repartidos entre el ERP, el CRM, la web y varias hojas de cálculo reciba propuestas para montar un data lake o un almacén de datos en la nube. A veces tienen sentido. Muchas otras, el problema real es más modesto: los datos no están conectados ni ordenados, y nadie puede responder rápido a preguntas básicas sobre el negocio.

Saber qué es cada cosa ayuda a no comprar una arquitectura más grande de lo que necesitas y a hacer las preguntas correctas al proveedor.

Explicamos los tres conceptos, cómo llegan los datos a cada uno (ETL y ELT), cuándo tiene sentido cada opción y por qué, en nuestra experiencia, a muchas empresas les basta con una base de datos PostgreSQL bien diseñada.

El data warehouse es el concepto más antiguo. Bill Inmon, uno de sus pioneros, lo definió como una colección de datos orientada a temas, integrada, que conserva el histórico y no se modifica, pensada para apoyar la toma de decisiones. En la práctica, los datos se limpian y se ordenan antes de entrar (lo que se llama esquema en escritura) y después se consultan con SQL desde herramientas de business intelligence. Es rápido y fiable para responder preguntas conocidas: ventas por mes, margen por cliente o evolución de los cobros.

El término data lake lo popularizó James Dixon, entonces CTO de Pentaho, hacia 2010. Un lago guarda los datos tal como llegan, normalmente en almacenamiento de objetos barato (como Amazon S3 o Azure Data Lake Storage), y se les da estructura al leerlos (esquema en lectura). Su ventaja es la flexibilidad: admite datos no estructurados y sirve para ciencia de datos y aprendizaje automático. Su riesgo más conocido es convertirse en un «pantano de datos» (data swamp): mucho volumen, poca documentación y nadie que sepa qué hay ni si es fiable.

El término lakehouse lo formalizaron en 2021 investigadores de Databricks en un artículo académico presentado en la conferencia CIDR. La idea es mantener los datos en almacenamiento barato y en formatos abiertos, como en un lago, y añadir encima una capa de metadatos que aporta lo que antes solo daba un almacén: transacciones ACID, versiones de los datos, auditoría e indexación. Esa capa la proporcionan formatos de tabla abiertos como Delta Lake o Apache Iceberg.

Plataformas como Databricks, Snowflake, Google BigQuery, Amazon Redshift o Microsoft Fabric ofrecen hoy, con distintos enfoques, combinaciones de almacén, lago y lakehouse. Las fronteras entre categorías se han difuminado, así que conviene fijarse menos en la etiqueta y más en qué problema resuelve cada herramienta.

Ninguna de las tres es una base de datos para el día a día de una aplicación. Están pensadas para analizar grandes volúmenes, no para registrar pedidos o facturas en tiempo real. Por eso casi siempre conviven con las bases de datos operativas de tus sistemas, de las que se alimentan.

Para que los datos lleguen al almacén o al lago hacen falta procesos de integración. El ETL (extraer, transformar y cargar) es el enfoque clásico: los datos se sacan de cada sistema, se limpian y se transforman fuera, y se cargan ya preparados en el almacén. El ELT (extraer, cargar y transformar) invierte el orden: primero se cargan en bruto y después se transforman dentro del propio almacén o lakehouse, aprovechando su potencia de cálculo. El ELT se ha extendido con los almacenes en la nube y herramientas como dbt, mientras que el ETL sigue siendo útil cuando hay que filtrar o anonimizar datos antes de guardarlos.

En los dos casos, lo que más trabajo da no es la herramienta, sino decidir qué significa cada dato: qué es un cliente activo, cuándo se considera cerrada una venta o qué fecha manda si el ERP y el CRM no coinciden.

Un data warehouse tiene sentido cuando tienes datos estructurados de varios sistemas, necesitas informes y cuadros de mando fiables y el volumen o el número de personas consultando a la vez empieza a ser alto para una base de datos convencional.

Un data lake tiene sentido cuando generas grandes volúmenes de datos variados o no estructurados (sensores, registros de máquinas o de aplicaciones, imágenes, documentos) y tienes, o vas a tener, un equipo de datos capaz de explotarlos, por ejemplo para entrenar modelos de aprendizaje automático. Un lakehouse encaja cuando necesitas las dos cosas a gran escala y quieres evitar mantener dos sistemas separados.

En las pymes con las que trabajamos, el cuello de botella rara vez es el volumen. Lo habitual es que los datos estén repartidos en herramientas que no se hablan, con criterios distintos y mucho trabajo manual para cruzarlos. Eso se resuelve integrando el ERP, el CRM y el resto de sistemas y ordenando los datos, no necesariamente con una plataforma de big data.

En Devyond no hemos montado ningún data lake, y en nuestros proyectos tampoco nos ha hecho falta BigQuery ni Snowflake. Un buen ejemplo es un caso que tenemos publicado: una proptech de inversión inmobiliaria de Valencia que tenía sus datos repartidos entre su CRM (HubSpot), su ERP (Odoo, con las operaciones y los proyectos) y su plataforma web (usuarios e inversiones). Integramos todo en una base de datos PostgreSQL que hace de fuente única de verdad y, encima, construimos un panel interno con cuadros de mando, KPI e informes.

En la práctica, esa base de datos cumple la función de un pequeño almacén de datos, y PostgreSQL ha ido sobrado para ese volumen. Según las métricas publicadas en el caso, el panel tiene más de 50 gráficos en tiempo real y ha supuesto un ahorro del 30 % del tiempo de gestión.

No somos los únicos que pensamos así. Entre desarrolladores circula desde hace años la idea de «Just use Postgres» (usa Postgres para todo), popularizada por el artículo «Just Use Postgres for Everything» de Stephan Schmidt, publicado en su blog Amazing CTO. Su argumento es que PostgreSQL, con sus extensiones, puede cubrir colas de mensajes, caché, búsqueda de texto, datos JSON o geoespaciales, y que reducir piezas reduce complejidad y coste. La idea tiene hasta libro propio: «Just Use Postgres!», de Denis Magda, publicado por Manning.

Conviene matizarlo. PostgreSQL es una base de datos pensada sobre todo para operaciones del día a día y guarda los datos por filas; los almacenes analíticos los guardan por columnas, lo que los hace mucho más eficientes cuando hay que recorrer cientos de millones de registros o cuando muchas personas lanzan consultas pesadas a la vez. Tampoco es buena idea lanzar análisis pesados contra la base de datos de producción: lo habitual es separar una copia o una base de datos para análisis. Pero para el volumen de la mayoría de pymes, un PostgreSQL bien diseñado y bien gestionado suele ser suficiente.

Esta empresa valoró hacer el proyecto con Power BI con otro proveedor. Power BI es una herramienta muy buena para el análisis, y en Devyond no la implantamos. El cliente eligió una solución a medida porque, además de integrar los datos y mostrarlos en una interfaz web sencilla para todo el equipo, sin la curva de aprendizaje de una herramienta de BI, le deja la puerta abierta a lanzar consultas y procesos hacia cada aplicación integrada, automatizar el conjunto e incluso conectar asistentes como ChatGPT o Claude al panel mediante MCP. Power BI ya permite lanzar acciones desde los informes, pero, en mi opinión, no tiene la profundidad ni la escalabilidad de un desarrollo a medida, donde no hay límites de la plataforma. Es excelente para analizar datos e ideal para analistas que trabajan con grandes volúmenes; pero cuando una herramienta la van a usar muchos empleados que necesitan cosas muy concretas, fáciles de entender y de usar, compensa una solución a medida.

Un data warehouse ordena datos estructurados para analizarlos, un data lake guarda datos en bruto de todo tipo y un lakehouse combina ambos enfoques. Tienen sentido con grandes volúmenes, datos variados y equipos de datos. Para la mayoría de pymes, lo prioritario es tener los datos conectados y ordenados, y para eso una base de datos PostgreSQL bien diseñada suele bastar.

Si quieres saber qué arquitectura de datos necesita de verdad tu empresa, te ayudamos con la ingeniería de datos: integramos tus sistemas en una fuente única y fiable. También puedes ver todo lo que hacemos en datos y business intelligence.

Cuéntanos qué sistemas usas y qué preguntas no puedes responder hoy con tus datos, y te diremos qué solución tiene sentido para tu caso.