Data Mesh: Why It's Not Working (and How to Fix It) - Part 1

Data Mesh promised to free domain teams and break centralized bottlenecks. Six years later, the bottlenecks are still here — just shuffled around. What went wrong? The problem isn’t your org chart. It’s your infrastructure.

Six years after the data mesh revolution began, the promises are still mostly unmet.

Teams were reorganized. Platforms were deployed. But the same problems keep reappearing: broken integrations, inconsistent schemas, and platforms that aren’t really self-serve.

The truth? You can’t fix centralization with a new org chart.

Domain ownership doesn’t work without infrastructure that makes it safe.

📐 Who is this post for?

• Data architects and platform engineers
• Data leaders and CDOs
• Domain teams frustrated by central bottlenecks
• Organizations struggling with data mesh implementations

…who want to understand why the data mesh vision remains elusive despite its compelling promise.

TL;DR

• Centralized data teams weren’t an accident. They were the result of irresistible forces: executive pressure, expensive infrastructure, and the rise of analytics as arcane knowledge.
• This birthed the “data tribute” problem — domain teams surrender data upward but get crumbs of value in return.
• Data Mesh (Dehghani, 2019) promised liberation through domain ownership, data-as-product, self-service platforms, and federated governance.
• Six years later, organizations keep hitting the same walls: fractured domains, broken integrations, undefined “data products,” paper-tiger governance, and lacking cross-domain support.
• Our tools are the problem: today’s data technologies assume centralization by design, lack formal data contracts, and fundamentally conflict with domain autonomy.

📢 Domain ownership doesn’t work without infrastructure that makes it safe. Until your platform supports versioning, contracts, and cross-domain consistency, your reorg is just moving deck chairs.

📚 What We’ll Cover

1. 🏛️ Why We Centralized Data in the First Place
2. ⚡ The Data Mesh Revolution
3. 🧱 Why Data Mesh Keeps Breaking in the Real World
4. ⚙️ Why Today’s Tools Fight Domain Ownership
5. What’s Next in Part 2

🏛️ Why We Centralized Data in the First Place

Centralized data teams weren’t organizational accidents. They were the inevitable outcome of powerful forces colliding:

• Executive Hunger for Global Insights: C-suite leaders demanding a God’s-eye view across the business
• Analytics as Arcane Knowledge: Data skills becoming specialized dark arts that domain teams rarely mastered
• Expensive Holy Infrastructure: Data warehouses costing millions, forcing shared ownership
• The One Truth Doctrine: Organizations desperately seeking salvation from contradictory reports

This centralization wasn’t just logical — it was existential.
Executives couldn’t bet their careers on data they didn’t trust.
Domain teams couldn’t interpret complex data.

The solution?

A specialized priesthood to translate raw data into actionable truth.

The Unintended Consequences

Over time, the central data team model, while initially solving critical needs, developed significant side effects:

• The Bottleneck Effect: Central teams inevitably became overwhelmed by requests from across the organization
• Worsening Dependency Cycles: Domain teams found themselves waiting weeks or months for critical data needs
• Knowledge Distance: Central teams lacked the deep domain expertise to properly interpret the data they modeled
• Disempowered Domain Teams: The teams closest to the business processes had the least influence over how their data was used
• One-Way Flow: Data flows up. Insight trickles down - if at all.
• Instrumentation Failure: Domain teams lacked incentives to instrument for analytical needs beyond their KPIs, while central teams lacked the expertise and safety to do so, creating a divide

This system was clearly broken. But what would replace it?

⚡ The Data Mesh Revolution

Zhamak Dehghani’s Vision

In 2019, Zhamak Dehghani published a revolutionary article on Martin Fowler’s blog that diagnosed this problem and proposed a radical rethinking of data architecture.

Her diagnosis was direct: centralized data teams couldn’t scale with the organization’s needs. The solution wasn’t to make central teams more efficient; it was to fundamentally rethink where data ownership should reside.

The Core Principles of Data Mesh

Dehghani’s framework rested on four transformative principles:

1. Domain Ownership: Teams that understand the business own their data products, not a central team
2. Data as Product: Data isn’t a byproduct but a first-class artifact with quality guarantees and user focus
3. Self-Service Platform: Common infrastructure that enables domain teams to build without specialized expertise
4. Federated Governance: Shared standards and practices without central bottlenecks

This approach inverted the traditional model.

Instead of operational teams providing raw material for central processing, domain teams would own data products from end to end, creating a distributed network of interconnected data assets.

The Promised Benefits

The data mesh vision resonated deeply because it promised to solve the most pressing problems of centralization:

• Organizational Scalability: Growth wouldn’t be constrained by central team capacity
• Knowledge Integration: Domain expertise would directly shape data products
• Responsive Evolution: Data products could evolve at the speed of business needs
• Empowered Teams: Source system owners would gain direct influence over analytics
• Two-Way Value Flow: Teams would both contribute to and derive value from the data ecosystem

For organizations struggling with the limitations of central data teams, this vision offered a path forward that aligned with modern principles of distributed systems and domain-driven design.

So why, six years later, are so many organizations still struggling to make this vision a reality?

🧱 Why Data Mesh Keeps Breaking in the Real World

The ideas are sound. The principles are solid. The reorgs happen.

But the same problems keep showing up — just with new job titles.

Here’s what that looks like in practice:

• Pilot projects fizzle before anything meaningful reaches production.
• New team charts emerge, but bottlenecks still live in Slack threads and standups.
• Docs and policies exist, but no one reads or enforces them.
• Domains own data… until it breaks something downstream.

The promise of autonomous, interconnected data teams becomes a messy sprawl of duplication, drift, and dependency.

The Four Walls Everyone Runs Into

🧱 Domain Consistency

The dream: Each domain builds its own clean, trustworthy data products.

The crash:

• “Customer” means different things in every domain.
• Schema drift makes reuse dangerous.
• No one agrees on what’s canonical — or even current.
• Past data gets mixed with present logic. No one notices… until something breaks.

🔗 Cross-Domain Integration

The dream: Domains build on each other’s work, forming a mesh of value.

The crash:

• An update in one domain silently breaks a downstream dependency.
• Teams integrate data with no guarantees it reflects the same point in time.
• Coordination happens manually — if it happens at all.
• “Just one small change” kicks off a five-team fire drill.

🛠️ Self-Service Platforms

The dream: Domains deploy data products without central help.

The crash:

• “Self-service” requires platform PhDs to operate.
• Every domain configures things differently — none are interoperable.
• Governance is a PDF, not an enforcement mechanism.
• Platform teams stay in the loop… because they have to.

🧑‍⚖️ Federated Governance

The dream: Common standards apply across domains, with room for flexibility.

The crash:

• Policies get written, then ignored.
• No shared tooling to verify compliance.
• Every exception becomes a precedent.
• Consumers can’t tell which data products are legit and which are duct-taped.

All These Walls Have the Same Foundation Problem

Reorgs don’t fail because people don’t believe. They fail because the platform can’t deliver.

You can’t federate trust without infrastructure that:

• Tracks versions
• Enforces contracts
• Guarantees consistency
• Supports publication workflows

Until that foundation exists, domain ownership is just a new name for the same old problems.

⚙️ Why Today’s Tools Fight Domain Ownership

Your tech stack wasn’t built for decentralization. It was built for central command-and-control — and it shows.

Let’s break down where it fails.

🧠 1. Databases That Forget

Most databases treat data like a whiteboard:

• Overwrites by default — every change erases the past
• No built-in time travel — history is a feature, not a guarantee
• No parallel versions — you can’t safely evolve without breaking others

The impact: Domain teams can’t iterate without risking someone else’s world. One change, and everything downstream shatters.

🛠️ 2. Orchestration That’s Blind to Data

Airflow, Prefect — they orchestrate processes, not data.

• Task-focused: What ran, not what exists
• Semantically blind: No clue what the output means
• No publish/promote model: You can’t stage and release data the way you do with code

The impact: You end up rebuilding fragile coordination logic by hand — and it looks an awful lot like a central team.

💣 3. ETL That Destroys as It Builds

ETL is supposed to move and shape data. But most pipelines are wrecking balls:

• Overwrites everything with no audit trail
• Corrupts downstreams if just one transformation breaks
• Requires heavy process to protect against accidental changes

The impact: Everyone’s afraid to touch the system. Change is expensive — and dangerous.

🧩 4. “Data Products” That Don’t Exist

Six years in, and we’re still arguing over what a “data product” actually is.

• No standard definition
• No versioning rules
• No explicit ownership or SLA
• No interface — just a table with a name

And data contracts? Mostly theoretical:

• No structured format
• No enforcement
• No compatibility guarantees
• No shared mental model

The impact: Teams operate on tribal knowledge and good faith. Then things break silently — or in public.

🔥 The Core Problem

Modern tools don’t support versioning, visibility, or safe collaboration across boundaries.
They assume a central team — with full context, infinite control, and no need to coordinate.

That assumption is breaking.

To fix it, we need infrastructure that understands the data domain — not just the pipeline.

What’s Next in Part 2

The challenges we’ve identified aren’t just problems to complain about — they’re design requirements for a solution. In Part 2 of this series, we’ll explore:

1. The Essential Infrastructure that makes true domain ownership possible
2. How AprioriDB is implementing these missing capabilities with real technical innovations
3. A path forward for organizations stuck between centralization pains and data mesh promises

If the core premise resonates—that data mesh requires technical foundations designed for domain autonomy—you’ll want to see how we’re addressing each of these barriers with infrastructure built from first principles.

📣 I’m passionate about creating the conditions for true domain ownership in data. If you’ve experienced the challenges we’ve discussed, I’d love to hear from you.

Written by Jenny Kwan, co-founder and CTO of AprioriDB.

Follow me on Bluesky and LinkedIn.

What do you think?

• What walls have you hit in your data mesh implementation?
• Do you see the connection between technical capabilities and organizational structures?
• What’s been your biggest challenge in implementing data mesh principles?

Share your experiences and thoughts in the comments below. 👇