Data Mesh and Lakehouse: Decentralized Data

For a decade, the promise was seductive: concentrate all of the organization's data in a single central repository, governed by a specialized team, and let the rest of the business consume information from there. First came the data warehouse, then the data lake. Yet, as companies across Latin America accelerate their digitalization, that centralized model is starting to show cracks: bottlenecks, overloaded teams, and business areas waiting weeks for a dashboard. In 2021, two approaches dominate the conversation about how to solve it: the lakehouse and the data mesh. They are not the same thing and, above all, they do not solve the same problem.

In short: The lakehouse is a technical architecture decision that unifies the data lake and the data warehouse into a single platform. The data mesh is an organizational decision that decentralizes responsibility over data toward the business domains. You can adopt one, the other, or both, but in no case does governance stop being the decisive factor.

Why the Centralized Model Starts to Fall Short

The traditional data warehouse brought order to the chaos: structured, clean data, ready for reporting. Its limit is rigidity. Loading new formats, semi-structured data, or high-frequency information is costly and slow. The data lake appeared to absorb all of that at low cost, but by allowing anything to be stored without structure, in many organizations it ended up turning into a swamp: data without context, without verifiable quality, and with no one accountable for it.

The underlying problem is not only technical. It is one of human scale. When a single central team must understand the sales business, logistics, finance, and operations in order to model their data, it becomes the bottleneck of the entire company. The areas that know the data best are not the ones that govern it, and those that govern it cannot fully understand every domain. That tension is what the two fashionable approaches try to relieve, each in its own way.

What the Lakehouse Is and What Problem It Solves

The lakehouse is an architecture that seeks the best of both worlds: the low cost and flexibility of the data lake with the structure, transactionality, and performance of the data warehouse. Instead of moving data from the lake to the warehouse in order to analyze it, a layer is applied that adds schema, version control, and transactional guarantees directly on top of low-cost storage.

What this enables in practice:

• A single copy of the data that serves both business analytics and data science and machine learning.
• Less duplication and fewer copy processes between systems, which reduces errors and maintenance costs.
• Support for structured and unstructured data on the same platform, without having to choose in advance.

The lakehouse is, above all, an architecture answer. It does not change who owns the data or how the team is organized; it changes where and how the data is stored and processed. That is why it fits well when the main pain is technological fragmentation: three different platforms, data copied back and forth, and infrastructure costs that are hard to justify.

What Data Mesh Is and Why It Is Different

Data mesh does not speak of servers or file formats, but of people and responsibilities. Its thesis is that data must stop being the property of a central team and become the responsibility of the business domains that originate it and understand it best. The logistics area owns its logistics data; the commercial area owns its own. Each domain publishes it, documents it, and is accountable for its quality.

It rests on four principles worth keeping in mind:

• Domain ownership: whoever generates the data governs it, not a team isolated from the business.
• Data as a product: each dataset is treated as a product, with an owner, documentation, agreed quality, and real consumers.
• Self-service platform: a central team provides common tooling so that domains can publish and consume data without reinventing the infrastructure.
• Federated governance: common rules of security, quality, and interoperability that are agreed upon by everyone and applied in a distributed way.

Data mesh is, then, an organizational decision before it is a technological one. Its greatest demand is not buying a platform, but changing how teams work and who is accountable. If you read it closely, you will notice that it is as much a matter of culture and operations as of technology, and that is the reason many pilots fail: the tool gets bought and the way of working does not change.

When Each One Is the Right Fit

The right question is not lakehouse or data mesh, because they do not compete. It's worth looking at where the real pain is.

• The lakehouse fits when the problem is one of platform: data scattered across systems that don't talk to each other, duplication costs, and analytics and data science teams fighting over different copies of the same information.
• The data mesh fits when the problem is one of organizational scale: an overwhelmed central data team, business domains that wait too long, and business knowledge that never reaches those who model the information.
• Both together make sense in large organizations, where the lakehouse provides the common technical platform and the data mesh defines how responsibilities are distributed over it.

For many mid-sized companies in the region, the prudent recommendation in 2021 is not to jump straight to data mesh. Decentralizing responsibility without first having brought order to the platform and governance usually multiplies the disorder rather than reducing it. Serious work in enterprise architecture helps define which problem is really being solved before choosing the model.

Governance Remains the Deciding Factor

Here is the point that both the lakehouse and the data mesh share: neither works without data governance. The lakehouse technically facilitates control, but it does not define who can see what, how quality is measured, or what a trustworthy data point means. The data mesh distributes responsibility, but without common federated rules each domain publishes with different criteria and interoperability breaks.

Governance defines the aspects that no architecture resolves on its own:

• Quality: what standard a data point must meet to be considered publishable and consumable.
• Security and privacy: who accesses what, with which controls, and under what regulatory framework.
• Shared meaning: that "active customer" means the same thing in logistics as in finance.
• Traceability: where each data point comes from and who is responsible for maintaining it.

Without these foundations, any investment in advanced analytics is built on sand. Technology accelerates; governance is what gives the confidence to make decisions with that data.

Frequently Asked Questions

Does the lakehouse replace the data warehouse?

Not necessarily. The lakehouse seeks to cover the use cases of both the warehouse and the lake on a single platform. If your current warehouse responds well to reporting needs, the migration should be justified by the cost of duplication or by the arrival of data science workloads, not by trend.

Is data mesh useful for a small company?

Rarely. Data mesh solves a scale problem: overwhelmed central teams and many autonomous domains. In a small organization, a well-structured central team is usually more efficient than distributing responsibilities that don't yet need to be distributed.

Can I have data mesh without a lakehouse?

Yes. Data mesh is an organizational model and can rely on different storage technologies. What cannot be missing is a self-service platform that keeps each domain from reinventing the infrastructure.

Where do I start if I have no data governance?

Right there, exactly. Before choosing an architecture, it's worth having a minimum of governance: clear owners, shared definitions, and quality rules. It is the foundation that makes any later model work.

The First Step

Before deciding between lakehouse, data mesh, or both, the most valuable step is to diagnose where the pain really is: is it platform, organization, or governance? That clarity avoids costly investments in the wrong direction. At SUMāTO we help companies in the region make that decision with judgment, connecting the technical architecture with the reality of the business. If you would like to discuss your case, write to us here and let's take that first step together.