Data lake vs data warehouse: la diferencia y cuál usar

Una distribuidora mediana decide “prepararse para la IA” y contrata un data lake. Ocho meses después, el lago tiene dos años de exportaciones del ERP, logs del sitio y archivos que nadie recuerda quién subió. El informe de margen por cliente sigue saliendo de una hoja de cálculo, hecha a mano, todos los lunes.

El debate data lake vs data warehouse suele empezar por el lado equivocado: qué tecnología es más moderna, cuál aguanta más volumen. Para la mayoría de las pymes, la pregunta útil es otra: ¿quién va a organizar este dato, y cuándo?

La diferencia entre data lake y data warehouse está en el momento en que se organiza el dato. El data warehouse recibe datos limpios y estructurados para responder preguntas conocidas, con SQL e informes. El data lake guarda todo en bruto, a bajo costo, y solo le da estructura al usarlo.

¿Cuál es la diferencia entre data lake y data warehouse en la práctica?

Los dos reúnen datos de varias fuentes en un solo lugar. Lo que cambia es dónde queda el trabajo. En el data warehouse defines antes el formato de cada tabla y el dato pasa por un proceso de ETL para entrar. En la documentación técnica se llama schema-on-write. En el data lake entra cualquier cosa tal como llega, y la estructura se aplica en la lectura: schema-on-read.

Parece un detalle de ingeniería, pero decide quién puede usar el dato. El trabajo de organizar no desaparece en el lake. Solo cambia de lugar y se paga con cada pregunta nueva, en general por alguien que sabe programar.

Criterio	Data warehouse	Data lake
Tipo de dato	Tablas estructuradas	Cualquiera: tablas, JSON, logs, imagen, audio
Cuándo se organiza	Antes de guardar	Al momento de usar
Quién lo usa	Analistas y gerentes, con SQL y BI	Ingenieros y científicos de datos
Mejor para	Informes, KPI, comparación de períodos	Entrenar modelos, explorar datos sin uso definido
Riesgo típico	Rigidez: cambiar el modelo da trabajo	Volverse un depósito que nadie puede consultar

¿El data lake es realmente más barato?

Es el argumento más repetido, y envejeció mal para quien maneja poco volumen. Compara los precios de lista de Google Cloud en la región de Iowa, consultados en noviembre de 2026. BigQuery, un data warehouse, cobra cerca de US$ 0,023 por GiB al mes en almacenamiento activo. Cloud Storage, base típica de un data lake, cobra cerca de US$ 0,02 en la clase Standard.

En 1 TB son US$ 23 contra US$ 20 al mes. Tres dólares no justifican una decisión de arquitectura. El lake solo sale mucho más barato en clases frías, como Coldline, a cerca de US$ 0,004 por GiB, pensadas para datos que casi nunca se leen. Y ese es el punto: el dato frío no responde la pregunta de nadie.

Mira una simulación de warehouse para un e-commerce con 40 GiB de historial. Pagas 30 GiB de almacenamiento, porque los 10 primeros son gratuitos: US$ 0,69 al mes. Los dashboards hacen 40 consultas diarias, cada una leyendo 2 GiB, lo que da cerca de 2,3 TiB al mes. Descontado 1 TiB gratuito, quedan 1,3 TiB a US$ 6,25: unos US$ 8,40. El total ronda los US$ 9 al mes.

Los números son un ejemplo, no un promedio de mercado, y los precios varían por región. Pero muestran dónde está el costo de verdad: en las personas. A este tamaño, lo caro son las horas de quien arma la carga y arregla lo que se rompe. Por eso la cuenta correcta compara cuánto tiempo de tu equipo consume cada opción, no el precio del gigabyte.

¿Por qué tantos data lakes se vuelven un pantano de datos?

El término en inglés es data swamp: un lake lleno de archivos sin dueño, sin descripción y sin control de versiones. La causa es simple. Guardar no cuesta esfuerzo, así que nadie decide qué entra. Seis meses después hay tres archivos llamados “clientes_final” y nadie sabe cuál vale.

“Guardar todo ahora y decidir después” suena prudente, pero suele aplazar la decisión difícil: definir qué es un cliente activo o cómo se calcula el ingreso. Sin esas definiciones, el problema de calidad solo queda mejor almacenado. El lake tampoco resuelve por sí solo los datos en silos: poner todo en el mismo balde no hace que las tablas conversen.

Evitar el pantano exige tres cosas: un catálogo de lo que existe, un dueño por conjunto de datos y una regla de retención. Si nadie en la empresa puede cuidar eso, todavía no está en condiciones de mantener un lake.

¿Cuál de los dos necesita tu empresa?

En la práctica, la mayoría de las pymes que llegó al límite de la hoja de cálculo necesita un data warehouse pequeño, y tal vez nunca un data lake. Ventas, medios pagos, CRM y finanzas son datos tabulares. Caben en tablas y las preguntas son conocidas: cuánto vendí, qué canal dio retorno, qué cliente desapareció.

El lake empieza a tener sentido cuando el dato no cabe en una tabla y alguien va a trabajarlo. Una red de clínicas que quiere analizar miles de llamadas grabadas, o una fábrica con sensores que registran cada segundo, tiene un caso real. Aun así, es raro que el lake reemplace al warehouse: el resultado del procesamiento suele terminar en tablas para que el gerente consulte.

Fíjate en la tercera pregunta. Tener el dato bruto no alcanza: si nadie va a trabajarlo, lo honesto es guardar una copia barata como seguro y seguir con el warehouse. Esa elección cuesta poco y se puede revisar después, sin una migración dolorosa.

¿El lakehouse reemplaza a los dos?

El lakehouse intenta unir los dos mundos: archivos baratos en el almacenamiento de un lake, con una capa que ofrece tablas y SQL como un warehouse. Tiene sentido técnico, pero no cambió el orden de prioridades. El informe 2026 de Dresner Advisory Services concluye que ninguna arquitectura domina: el data warehouse es el preferido del 54% de los encuestados y el lakehouse aparece con 29% de adopción. La adopción de data lake sube del 42% al 62% a medida que las empresas avanzan en madurez de IA.

Ese último número merece atención, y no por el motivo obvio. El lake crece donde ya existe capacidad de IA, no al revés. Comprar un lake no produce madurez. Para una pyme, el lakehouse es un tema para cuando haya ingeniería de datos dedicada. Antes de eso, suma complejidad sin resolver un dolor concreto.

Cómo empezar sin equivocar el orden

1. Lista las diez preguntas que el negocio hace cada mes y qué sistemas responden cada una.
2. Escribe las definiciones que generan discusión: ingreso, cliente activo, lead calificado.
3. Conecta solo las fuentes de esas preguntas a un warehouse administrado, sin servidores que mantener.
4. Usa una herramienta de carga lista antes de pensar en escribir código propio.
5. Evalúa un lake solo cuando aparezca un dato que no cabe en este modelo y alguien con tiempo para trabajarlo.

Preguntas frecuentes

¿Data lake y data warehouse pueden coexistir?

Sí, y en empresas grandes es lo común. El lake recibe el dato bruto y el warehouse guarda la versión tratada para consultar. Solo no conviene montar los dos a la vez sin necesidad, porque duplicas el mantenimiento.

¿Qué es mejor para inteligencia artificial?

Depende del tipo de IA. Entrenar modelos propios con texto, imagen o audio pide un lake. Hacer preguntas sobre ventas y campañas pide datos organizados y bien definidos, o sea, un warehouse. Un modelo de lenguaje leyendo una tabla confusa se equivoca con mucha seguridad.

¿Excel o Google Sheets pueden ser un data warehouse?

No. La hoja de cálculo sirve para análisis puntuales, pero no conserva el historial de forma confiable ni controla la carga. Con dos fuentes y pocas filas, en cambio, puede bastar por bastante tiempo.

¿Qué son ETL y ELT en este contexto?

En ETL, el dato se transforma antes de entrar al destino, el patrón clásico del warehouse. En ELT, entra bruto y se transforma después, dentro de la propia plataforma. El ELT se volvió común porque los warehouses en la nube tienen procesamiento de sobra, y eso acercó los dos mundos.

Empieza por la pregunta, no por la arquitectura

Quien elige infraestructura antes de saber qué quiere preguntar casi siempre termina con un proyecto elegante y la misma hoja de los lunes. El data warehouse es la opción por defecto para quien tiene preguntas de negocio; el data lake responde a un problema específico que muchas empresas todavía no tienen. En varios casos, ni siquiera el warehouse es el primer paso. Si el dolor es cruzar plataformas de anuncios, CRM y hojas de cálculo para responder preguntas del día a día, Sherlok conecta esas fuentes y entrega el análisis listo a partir de una pregunta en lenguaje natural, sin proyecto de infraestructura.