Durante una década, la promesa fue seductora: concentrar todos los datos de la organización en un único repositorio central, gobernado por un equipo especializado, y dejar que el resto del negocio consumiera información desde allí. Primero fue el data warehouse, después el data lake. Sin embargo, a medida que las empresas en América Latina aceleran su digitalización, ese modelo centralizado empieza a mostrar grietas: cuellos de botella, equipos saturados y áreas de negocio que esperan semanas por un tablero. En 2021 dos enfoques dominan la conversación para resolverlo: el lakehouse y el data mesh. No son lo mismo y, sobre todo, no resuelven el mismo problema.
En corto: El lakehouse es una decisión de arquitectura técnica que unifica data lake y data warehouse en una sola plataforma. El data mesh es una decisión organizativa que descentraliza la responsabilidad sobre los datos hacia los dominios de negocio. Puede adoptar uno, el otro o ambos, pero en ningún caso el gobierno deja de ser el factor decisivo.
El data warehouse tradicional ordenó el caos: datos estructurados, limpios y listos para reportería. Su límite es la rigidez. Cargar formatos nuevos, datos semiestructurados o información de alta frecuencia resulta costoso y lento. El data lake apareció para absorber todo eso a bajo costo, pero al permitir guardar cualquier cosa sin estructura terminó, en muchas organizaciones, convertido en un pantano: datos sin contexto, sin calidad verificable y sin nadie que responda por ellos.
El problema de fondo no es solo técnico. Es de escala humana. Cuando un único equipo central debe entender el negocio de ventas, de logística, de finanzas y de operaciones para modelar sus datos, se vuelve el cuello de botella de toda la compañía. Las áreas que mejor conocen el dato no son las que lo gobiernan, y las que lo gobiernan no alcanzan a conocer cada dominio. Esa tensión es la que los dos enfoques de moda intentan aliviar, cada uno por su lado.
El lakehouse es una arquitectura que busca lo mejor de los dos mundos: el bajo costo y la flexibilidad del data lake con la estructura, la transaccionalidad y el rendimiento del data warehouse. En lugar de mover datos del lake al warehouse para poder analizarlos, se aplica una capa que aporta esquema, control de versiones y garantías transaccionales directamente sobre el almacenamiento de bajo costo.
Lo que esto habilita en la práctica:
El lakehouse es, ante todo, una respuesta de arquitectura. No cambia quién es dueño de los datos ni cómo se organiza el equipo; cambia dónde y cómo se almacenan y procesan. Por eso encaja bien cuando el dolor principal es la fragmentación tecnológica: tres plataformas distintas, datos copiados de un lado a otro y un costo de infraestructura difícil de justificar.
El data mesh no habla de servidores ni de formatos de archivo, sino de personas y responsabilidades. Su tesis es que los datos deben dejar de ser propiedad de un equipo central y pasar a ser responsabilidad de los dominios de negocio que los originan y mejor los entienden. El área de logística es dueña de sus datos de logística; el área comercial, de los suyos. Cada dominio los publica, los documenta y responde por su calidad.
Se apoya en cuatro principios que conviene tener presentes:
El data mesh es, entonces, una decisión organizativa antes que tecnológica. Su mayor exigencia no es comprar una plataforma, sino cambiar cómo trabajan los equipos y quién rinde cuentas. Si lo lee con atención, notará que es tanto un asunto de cultura y operación como de tecnología, y esa es la razón por la que muchos pilotos fracasan: se compra herramienta y no se cambia la forma de trabajar.
La pregunta correcta no es lakehouse o data mesh, porque no compiten. Conviene mirar dónde está el dolor real.
Para muchas empresas medianas en la región, la recomendación prudente en 2021 es no saltar directo al data mesh. Descentralizar la responsabilidad sin antes haber ordenado la plataforma y el gobierno suele multiplicar el desorden en lugar de reducirlo. Un trabajo serio de arquitectura empresarial ayuda a definir qué problema se está resolviendo realmente antes de elegir el modelo.
Aquí está el punto que tanto el lakehouse como el data mesh comparten: ninguno funciona sin gobierno de datos. El lakehouse facilita técnicamente el control, pero no define quién puede ver qué, cómo se mide la calidad ni qué significa un dato confiable. El data mesh distribuye la responsabilidad, pero sin reglas comunes federadas cada dominio publica con criterios distintos y la interoperabilidad se rompe.
El gobierno define los aspectos que ninguna arquitectura resuelve sola:
Sin estos cimientos, cualquier inversión en analítica avanzada se construye sobre arena. La tecnología acelera; el gobierno es lo que da confianza para decidir con esos datos.
No necesariamente. El lakehouse busca cubrir los casos de uso del warehouse y del lake en una sola plataforma. Si su warehouse actual responde bien a las necesidades de reportería, la migración debe justificarse por el costo de duplicación o por la llegada de cargas de ciencia de datos, no por moda.
Rara vez. El data mesh resuelve un problema de escala: equipos centrales desbordados y muchos dominios autónomos. En una organización pequeña, un equipo central bien estructurado suele ser más eficiente que repartir responsabilidades que aún no necesitan repartirse.
Sí. El data mesh es un modelo organizativo y puede apoyarse en distintas tecnologías de almacenamiento. Lo que no puede faltar es una plataforma de autoservicio que evite que cada dominio reinvente la infraestructura.
Por ahí, exactamente. Antes de elegir arquitectura, conviene tener un mínimo de gobierno: dueños claros, definiciones compartidas y reglas de calidad. Es el cimiento que hace que cualquier modelo posterior funcione.
Antes de decidir entre lakehouse, data mesh o ambos, el paso más valioso es diagnosticar dónde está realmente el dolor: ¿es de plataforma, de organización o de gobierno? Esa claridad evita inversiones costosas en la dirección equivocada. En SUMāTO acompañamos a empresas de la región a tomar esa decisión con criterio, conectando la arquitectura técnica con la realidad del negocio. Si desea conversar sobre su caso, escríbanos aquí y demos juntos ese primer paso.