Zhamak Dehghani’s data mesh principles swept through the data engineering world like a revelation. After years of struggling with monolithic data warehouses and bottlenecked central data teams, the idea of treating data as a product and distributing ownership to domain teams felt like liberation. Finally, a framework that acknowledged the organizational reality: central data teams don’t scale, domain expertise matters, and data infrastructure should be a platform, not a bottleneck.

Three years later, a significant number of organizations that adopted data mesh are quietly abandoning it — not with public announcements, but through gradual recentralization. Teams that were supposed to own their data products are escalating to a central team. Platform investments that were supposed to enable self-service are being used as managed services by domain teams that can’t operate them independently.

Not because the principles are wrong. They aren’t. But because the gap between the theory and the implementation reality is wider than most organizations can bridge — and because advocates dramatically underestimate the organizational prerequisites.

What Data Mesh Gets Right

Let’s give credit where it’s due. Data mesh correctly identifies three real problems that plague traditional data architectures:

1. Central Data Teams Don’t Scale

When every analytics question, every new pipeline, and every data model change routes through a central data team, that team becomes the organization’s most persistent bottleneck. Request queues grow into months-long backlogs. Context gets lost in translation between domain experts who understand the business and data engineers who understand the technology but not the domain nuances.

The central data team builds pipelines for marketing, finance, operations, and product — domains they understand superficially at best. The result: pipelines that technically work but produce data that doesn’t match the domain’s mental model. “Active users” means something different to product (daily logins), marketing (email engagement), and finance (paying subscribers). A central team arbitrarily picks one definition and calls it canonical.

2. Domain Knowledge Matters

The marketing team understands marketing data better than a central data engineer ever will. They know which campaign metrics are meaningful, which attribution models are appropriate, and which data sources contain clean data versus approximations. The finance team understands accrual vs. cash accounting, revenue recognition rules, and regulatory reporting requirements.

When domain experts own their data products, the quality of the data models improves dramatically because the people making modeling decisions actually understand the domain.

3. Data Infrastructure Should Be a Platform

Instead of every team building their own Spark clusters, their own orchestration pipelines, and their own quality monitoring, a central platform should provide self-service tools that domain teams consume. This is the data equivalent of a platform engineering team: build the road, let the domain teams drive.

All correct. All important. And all achievable without full data mesh adoption.

What Goes Wrong

The Talent Problem

Data mesh assumes that every domain team has — or can quickly hire — engineers capable of building and maintaining production-grade data products. These aren’t simple CSV exports. Data products require schema management, quality testing, freshness monitoring, SLA compliance, documentation, versioning, and consumer support.

A typical mid-market company has 3-5 strong data engineers across the entire organization. Data mesh asks you to distribute these engineers across 8-12 domain teams, each of which needs at minimum 2 dedicated data engineers (one for development, one for continuity). The math doesn’t work: you need 16-24 data engineers but have 3-5.

The workaround — training existing domain engineers to become data engineers — consistently underperforms. Building production data pipelines requires specific skills: understanding distributed systems, data modeling, quality engineering, and pipeline operations. A backend engineer can learn these skills, but the ramp-up time is 12-18 months, and during that time the domain team produces immature data products that downstream consumers can’t rely on.

You end up with domain teams that nominally own data products they can’t actually maintain, and a platform team that’s responsible for everything but empowered to fix nothing. The organizational structure says “decentralized” — the operational reality is “central team doing everything while pretending they’re not.”

The Standards Problem

“Federated computational governance” sounds elegant in a conference keynote. In practice, it means 12 teams making independent decisions about data quality standards, naming conventions, SLA definitions, schema evolution policies, and metric calculations.

Team A defines “customer” as anyone with an account. Team B defines “customer” as anyone who’s made a purchase. Team C defines “customer” as anyone active in the last 90 days. Team D has two definitions depending on which report you’re looking at.

When the CEO asks “how many customers do we have?” — you get four different numbers, a 45-minute meeting to figure out whose definition is correct, and a lingering loss of trust in the data organization. This is the exact problem data mesh was supposed to solve — and in many implementations, it makes it worse by distributing the authority to define terms without centralizing the governance to ensure consistency.

Federated governance requires something most organizations lack: a mature culture of cross-team alignment where independent teams voluntarily adopt shared standards and hold each other accountable. Without that culture, federation is just fragmentation with better branding.

The Incentive Problem

Domain teams exist to serve their domain’s business objectives. The sales team’s job is to close deals. The marketing team’s job is to generate leads. The finance team’s job is to manage the organization’s money. None of these teams have a primary incentive to maintain a high-quality data product for another team’s consumption.

“But it’s a cultural shift!” advocates say. Sure. But cultural shifts don’t happen by declaration. They happen when incentives align. And in most organizations, there’s no reward for maintaining a data product that primarily benefits another department. The marketing team’s OKRs don’t include “maintain a data product that the finance team relies on for revenue attribution.” Why would they invest time in consumer SLAs when they’re being measured on campaign performance?

The Platform Maturity Problem

Data mesh requires a self-service data platform that domain teams can use independently. This platform needs to handle: data ingestion, transformation orchestration, quality testing, schema registry, access control, discoverability (a data catalog), monitoring, alerting, and documentation — all through self-service interfaces that non-specialists can operate.

Building such a platform takes 18-24 months of dedicated platform engineering investment. Most organizations that adopt data mesh start building the platform simultaneously with distributing data ownership — which means domain teams are asked to own data products using tools that don’t yet exist.

The Decision Framework

Data mesh is not always wrong. But it has prerequisites that most organizations don’t meet. Use this framework honestly:

When Data Mesh Works

• Large organizations (500+ engineers) with mature engineering practices and deep talent pools
• Strong existing data culture where domain teams already have data engineering capability — not aspirationally, actually
• Executive sponsorship with real authority and real accountability for data product quality across domains
• Sufficient talent to staff domain-level data product teams — minimum 2 data engineers per domain, not shared across domains
• Mature platform team (established for 12+ months) capable of providing genuinely self-service data infrastructure

When Data Mesh Fails

• Mid-market organizations (50-200 engineers) without deep data engineering talent pools
• Low data maturity where basic data governance — naming standards, metric definitions, quality monitoring — hasn’t been established
• Siloed culture where cross-functional collaboration is aspirational but not practiced
• Budget constraints that prevent hiring dedicated data engineers for each domain

The Middle Path

For most organizations, the right answer is neither a fully centralized data warehouse nor a fully decentralized data mesh. It’s a pragmatic hybrid:

1. Central platform team provides data infrastructure, quality frameworks, and enterprise-wide standards
2. Domain teams own data models and business logic but use centralized tooling and follow centralized governance standards
3. Central governance defines enterprise-wide definitions (what is a “customer”? what is “revenue”?) with input from domain stakeholders
4. Domain-level data stewards (not full-time data engineers) maintain domain data quality using the platform’s self-service tools
5. Central data engineering handles complex, cross-domain data products that require integration across multiple domains

This isn’t as intellectually pure as data mesh. It doesn’t make for a compelling conference talk. But it works for organizations that exist in the real world with real talent constraints, real budget limitations, and real cultural maturity levels.

The Honest Assessment

Before adopting data mesh, answer honestly:

1. Can every domain team hire and retain a data engineer? If not, who will maintain the data products when the initial enthusiasm fades?
2. Do you have executive sponsorship for cross-domain data standards? If not, who will resolve the inevitable definition conflicts that federation creates?
3. Is your data platform mature enough to provide self-service tooling? If not, you’re asking domain teams to build infrastructure AND data products simultaneously — while also doing their actual domain work.
4. Does your organizational culture support voluntary cross-team governance? If not, federation will produce fragmentation, not freedom.

If any answer is “no,” data mesh will create more problems than it solves. And that’s okay. Start with a strong central data team, mature your governance practices, build the platform, and revisit the decentralization question in 18-24 months when the prerequisites are in place.

---

The Garnet Grid perspective: Data architecture decisions should be driven by organizational capability, not conference hype. We help organizations choose the architecture that fits their reality — not their aspirations. Explore our data engineering consulting →