Data warehouse, data lake o lakehouse: cuál necesitas realmente

La respuesta corta para la mayoría de las organizaciones medianas: necesitas un data warehouse moderno en la nube, y probablemente no necesitas un data lake todavía. Si alguien te está proponiendo un lakehouse antes de que tengas resuelto el reporteo básico, te está vendiendo la arquitectura de un problema que no tienes.

Aquí está la diferencia real y el criterio para decidir.

Las tres opciones, sin jerga

Data warehouse. Los datos llegan ya estructurados en tablas, con un esquema definido antes de guardarlos. Está optimizado para responder preguntas de negocio rápido: ventas por región, clientes por segmento, margen por producto. Es lo que sostiene tableros y reportes.

Data lake. Los datos llegan como están —archivos, registros de eventos, imágenes, texto— sin estructura previa, y se interpretan al momento de leerlos. Está optimizado para volumen y flexibilidad. Es lo que sostiene ciencia de datos y entrenamiento de modelos sobre datos crudos.

Lakehouse. Un intento de tener las dos cosas: almacenamiento flexible como un lake, con capacidades transaccionales y de consulta como un warehouse.

La distinción práctica está en cuándo decides la estructura: antes de guardar (warehouse) o al momento de leer (lake). Todo lo demás se deriva de ahí.

Por qué la mayoría no necesita un data lake

El argumento a favor del data lake suele ser: “guardemos todo por si acaso, ya veremos qué hacer con eso después”. Suena prudente y sale caro.

Lo que pasa en la práctica es predecible. Se guardan terabytes de datos sin estructura, nadie los documenta, y dos años después nadie sabe qué contiene cada carpeta ni si es confiable. El término del sector para esto es data swamp, y no es una broma: es el resultado por defecto cuando se guarda sin gobierno.

Un data lake tiene sentido cuando ya tienes un caso de uso que lo requiere:

• Volúmenes de datos semiestructurados que un warehouse no absorbe con costo razonable
• Ciencia de datos sobre datos crudos, donde la estructura previa estorba
• Datos no tabulares como imágenes, audio o texto libre a gran escala
• Retención de datos históricos que se consultan pocas veces al año

Si ninguno aplica hoy, guardar “por si acaso” es un costo presente contra un beneficio hipotético.

Qué resuelve un data warehouse moderno

La razón por la que esta discusión cambió es que los warehouses en la nube absorbieron buena parte de lo que antes obligaba a tener un lake.

Un warehouse moderno como Snowflake separa el cómputo del almacenamiento, lo que significa que puedes guardar mucho y pagar cómputo solo cuando consultas. Maneja datos semiestructurados —JSON, por ejemplo— de forma nativa, sin aplanarlos antes. Escala la concurrencia sin que un proceso pesado bloquee los tableros. Y no requiere administración de infraestructura.

Ese conjunto de capacidades cubre el caso de la gran mayoría de las organizaciones medianas, incluyendo bastante analítica avanzada. El lake deja de ser un requisito y pasa a ser una decisión que se toma cuando aparece la necesidad concreta.

El criterio de decisión

Tu situación hoy	Lo que necesitas
Reportes en Excel, datos en varios sistemas que no se hablan	Warehouse en la nube. Es todo. No compliques.
Warehouse funcionando, quieres analítica avanzada sobre datos tabulares	El mismo warehouse. Escala mejor de lo que crees.
Datos de sensores, registros de eventos o multimedia a gran escala	Warehouse + lake para esos datos específicos
Equipo de ciencia de datos trabajando sobre datos crudos	Lakehouse o warehouse + lake, según el equipo
No tienes reporteo confiable todavía	Warehouse, y resuelve las definiciones antes de sumar capas

Ese último renglón es el más importante y el que más se salta. Si hoy dos áreas reportan cifras distintas para el mismo indicador, ninguna de estas tres arquitecturas lo arregla, porque el problema está en las definiciones, no en el almacenamiento. Ahí el trabajo es una capa semántica.

La pregunta que revela la respuesta real

Cuando alguien nos pregunta cuál elegir, devolvemos esta: ¿cuántas de las preguntas que tu negocio necesita responder hoy quedan sin respuesta por falta de arquitectura, y cuántas por falta de datos integrados?

Casi siempre la respuesta es la segunda. El bloqueo no es que el warehouse no aguante: es que los datos siguen en el ERP, el CRM y la plataforma de comercio, sin cruzarse. Eso se resuelve con ingesta —Fivetran o Informatica— hacia el warehouse que ya tienes o el que vas a poner.

Elegir arquitectura antes de resolver la ingesta es optimizar el paso 3 mientras el paso 1 sigue roto.

Sobre la presión de la IA

Un argumento que aparece seguido: “necesitamos un lake porque vamos a hacer IA”. Conviene desarmarlo.

Para la mayoría de los casos de uso de IA empresarial —pronósticos, segmentación, detección de anomalías, agentes que responden preguntas de negocio— los datos que hacen falta son tabulares y estructurados, y viven perfectamente en un warehouse. La IA generativa sobre documentos internos es un caso distinto, pero se resuelve con almacenamiento de documentos y búsqueda vectorial, no con un lake de propósito general.

Lo que la IA sí exige es lo que casi nadie quiere oír: definiciones únicas, permisos aplicados en los datos y linaje auditable. Eso es trabajo de modelado y gobierno, no de elegir motor de almacenamiento. Es la conversación de la AI-Ready Foundation.

Nuestra recomendación

Empieza con un warehouse en la nube, integra tus fuentes principales, define tus métricas una sola vez, y añade un lake el día que tengas un caso de uso que el warehouse no cubra con costo razonable. Ese día llegará o no llegará, y en cualquier caso habrás construido lo que sí necesitabas primero.

Si estás en medio de esta decisión y quieres una opinión sin agenda de proveedor, platiquemos. También te puede servir revisar las señales de que tus datos no están listos para IA antes de comprometer presupuesto.