Data mesh was supposed to fix everything wrong with centralised data platforms. Give domain teams ownership of their data. Treat data as a product. Federate governance. Let the people closest to the data manage it.

Zhamak Dehghani’s original concept, published back in 2019, was compelling. By 2024, Gartner had it firmly on their hype cycle. Now, in early 2026, enough organisations have tried implementing data mesh that we can see what actually happens when theory meets corporate reality.

The results are mixed. That’s worth talking about honestly.

What Data Mesh Gets Right

The core insight of data mesh is sound: centralised data teams become bottlenecks. When every analytics request has to go through one team, that team becomes overloaded, turnaround times blow out, and domain experts get frustrated waiting weeks for queries they could write themselves.

Distributing data ownership to domain teams — giving marketing ownership of marketing data, giving operations ownership of operational data — makes organisational sense. The people who understand the data best should manage it.

Companies that have successfully adopted elements of data mesh report faster time-to-insight. Domain teams can answer their own questions without submitting tickets and waiting in queue. That alone justifies the approach for many organisations.

McKinsey’s 2025 data and analytics survey found that organisations with distributed data ownership reported 40% faster decision-making cycles than those relying solely on centralised data teams.

Where It Falls Apart

Here’s where it gets complicated. Data mesh assumes your domain teams have the technical capability to manage data products. They need to understand data modelling, quality standards, API design, and governance requirements.

Most domain teams don’t have these skills. They have business expertise, which is valuable but different. Asking a marketing team to also become data engineers is like asking your accountant to also manage your network infrastructure. They’re different disciplines.

The common workaround is embedding data engineers within domain teams. This works, but it’s expensive. You need multiple skilled data professionals instead of one centralised team. For a large enterprise with deep pockets, that’s manageable. For a mid-market company with 200 employees, it’s a significant investment.

The Governance Paradox

Data mesh advocates for federated governance — domain teams follow agreed standards but manage their own implementation. In theory, this balances autonomy with consistency.

In practice, federated governance requires extraordinary discipline. Every domain team needs to follow the same naming conventions, quality standards, documentation practices, and access controls. Without active enforcement, standards drift. Team A uses one date format. Team B uses another. Team C doesn’t document anything because they’re busy with other priorities.

Within 12 months, you’ve got the same data quality problems you started with, just distributed across more teams.

Gartner’s 2025 analysis noted that 65% of organisations attempting data mesh reported governance consistency as their primary challenge. The technology wasn’t the hard part. The organisational discipline was.

What’s Actually Working: The Hybrid Approach

The organisations seeing the best results aren’t doing pure data mesh. They’re taking the useful parts and combining them with centralised capabilities where it makes sense.

This looks like: domain teams own their data products and are responsible for data quality at the source. But a central platform team provides the infrastructure, tooling, and governance framework. Think of it as the central team building the roads while domain teams drive on them.

Woolworths Group has spoken at industry events about their approach, which borrows heavily from data mesh principles without fully decentralising everything. They’ve kept a strong central data platform while giving domain teams more ownership over how their specific data products are defined and maintained.

This hybrid model reduces the skills burden on domain teams. They don’t need to be infrastructure experts. They need to understand their data well and follow established standards for sharing it.

Should Mid-Market Companies Bother?

If you’ve got fewer than 500 employees, full data mesh is probably overkill. The organisational overhead of distributed ownership across multiple small teams doesn’t justify the benefits.

But the principles are still valuable. Even in a centralised model, you can apply data mesh thinking:

Treat data as a product. Every dataset should have an owner, documentation, quality standards, and a clear purpose. If nobody owns it, it deteriorates.

Give domain experts a voice. Even if a central team manages the infrastructure, the people who use the data should define what they need and validate quality. Don’t let data teams operate in a vacuum.

Standardise interfaces. Whether you’re using APIs, shared databases, or data lakes, agree on how data moves between teams. Ad hoc integration creates technical debt fast.

The Honest Assessment

Data mesh isn’t a silver bullet. It’s an architectural pattern that works well in specific contexts — large organisations with mature data capabilities and well-defined domain boundaries.

For everyone else, the principles are more useful than the full implementation. Take what makes sense for your scale and complexity. Ignore the rest. And be deeply suspicious of anyone who tells you there’s one right way to organise your data architecture.

Your data problems are specific to your organisation. Your solutions should be too.