Data Mesh vs Data Fabric: A Practical View

Few topics in data architecture generate as much confusion as Data Mesh and Data Fabric. Vendors claim to offer both. Analysts use them interchangeably. And practitioners aren't sure which one they should be pursuing.

Let's cut through the noise.

What They Actually Are

Data Mesh: An Organisational Model

Data Mesh, coined by Zhamak Dehghani, is fundamentally about organisation and ownership, not technology.

The four principles:

1. Domain ownership: Business domains own their data as products
2. Data as a product: Data is treated with the same rigour as customer-facing products
3. Self-serve platform: A platform team enables domains to publish data independently
4. Federated governance: Governance is collaborative, not centralised

Data Mesh is a response to the failure of centralised data teams to scale. Instead of one team being the bottleneck, domains take responsibility for their own data.

Data Fabric: A Technology Architecture

Data Fabric is a technology pattern for unifying data access across distributed systems.

Key capabilities:

1. Unified metadata: A single view of all data assets
2. Semantic layer: Consistent business definitions across sources
3. Automated integration: AI-assisted data discovery and mapping
4. Virtualisation: Query data where it lives, without moving it
5. Governance enforcement: Policy applied consistently across sources

Data Fabric is a response to data sprawl. Instead of moving all data to one place, it provides a layer that makes disparate sources feel unified.

When to Use Each

Data Mesh Makes Sense When:

• You have distinct business domains with clear ownership (e.g., marketing, finance, operations)
• Centralised data teams are a bottleneck — domains wait weeks for data products
• Domains have sufficient maturity to own data products (or can develop it)
• You're willing to invest in a self-serve platform to enable domains
• Your organisation can handle federated governance (not every organisation can)

Data Fabric Makes Sense When:

• You have many disparate data sources that need unified access
• Data movement is expensive, slow, or prohibited (e.g., due to regulation)
• You need a consistent semantic layer across sources
• You want to augment existing investments rather than replace them
• Users need to query across sources without knowing where data lives

They Can Work Together

Here's the thing: Data Mesh and Data Fabric aren't mutually exclusive.

A mature implementation might have:

• Domains owning data products (Mesh principle)
• A unified metadata catalogue (Fabric capability)
• Self-serve platform with virtualisation (Mesh + Fabric)
• Federated but consistent governance (both)

The Mesh provides the organisational model; the Fabric provides some of the technical capabilities that enable it.

The Reality Check

Data Mesh Challenges

Most Data Mesh implementations struggle because:

1. Domains aren't ready: Owning data products requires skills most domains don't have
2. Platform underinvestment: Without a robust self-serve platform, domains can't succeed
3. Governance gaps: Federated governance sounds good but is hard to execute
4. Cultural resistance: Data teams don't want to give up control; domains don't want new responsibilities

Data Fabric Challenges

Data Fabric implementations struggle because:

1. Vendor overselling: Most "Fabric" products only deliver a fraction of the vision
2. Integration complexity: Connecting to every source with consistent semantics is hard
3. Performance issues: Virtualisation can't match the performance of materialised data
4. Governance gaps: It's easy to expose data; it's hard to ensure it's governed

A Pragmatic Path Forward

Rather than adopting a label, focus on solving real problems:

Step 1: Assess Your Bottlenecks

Ask: where does data delivery break down?

• If it's organisational (central team overloaded), Mesh principles help
• If it's technical (can't access data across sources), Fabric capabilities help
• If it's both, you need elements of each

Step 2: Start Small

Don't try to implement either at enterprise scale on day one.

For Mesh:

• Pick one domain with data maturity and motivation
• Build the minimal platform they need to succeed
• Learn before expanding

For Fabric:

• Connect two or three sources that need unified access
• Build the metadata foundation first
• Add capabilities incrementally

Step 3: Invest in Foundations

Regardless of which direction you go, you need:

| Foundation | Why It Matters | |------------|----------------| | Data Catalogue | Can't govern what you can't see | | Common Definitions | Mesh or Fabric, consistency matters | | Quality Standards | Decentralised production needs standards | | Platform Team | Someone has to build the enabling infrastructure |

Step 4: Be Honest About Maturity

Both patterns require significant organisational maturity:

• Mesh requires domain autonomy and accountability
• Fabric requires cross-functional platform teams

If you don't have these, you're not ready for either — and that's fine. Start by building the foundations.

What We Recommend

For most organisations, we recommend:

1. Don't adopt a label — adopt specific practices that solve your problems
2. Start with the catalogue — you can't manage what you can't find
3. Build self-serve capabilities — whether centralised or federated, reduce bottlenecks
4. Clarify ownership — every dataset should have an owner, even if central teams still build
5. Standardise incrementally — don't try to define everything upfront

Over time, you'll likely end up with something that looks like a hybrid — and that's fine. The goal is effective data management, not architectural purity.

Further Reading

• Zhamak Dehghani: Data Mesh Principles
• Gartner: Data Fabric Architecture
• Thoughtworks: Data Mesh in Practice