Data mesh

What is data mesh?

Data mesh is an organisational model for data, described in 2019 by Zhamak Dehghani. The core idea: stop trying to have one central data team manage every dataset in a large organisation. Give each domain (sales, logistics, finance, HR) ownership of its own data and let them publish it as data products to the rest of the organisation.

Data mesh is not a product and not a technology. It is a way of working. It can be implemented on any data platform, from Microsoft Fabric to Snowflake to a home-grown stack. What matters is how responsibilities are split.

Compare data mesh to how microservices changed the application world. Instead of one big monolith owned by one team, you build many smaller services, each owned by a team with the domain knowledge. The same is happening here for data.

Why data mesh?

Classic data warehouses and lakehouses centralise data on one platform run by a central data team. That works fine in smaller organisations but gets stuck in large ones on three counts.

Bottleneck at the central team
Every new request from every domain goes through the same team. The backlog grows, lead times stretch to months, frustration climbs.

Loss of domain knowledge
A central team cannot know fifty different business processes in detail. Mistakes creep in, semantics get translated by someone who does not live with them daily.

Unrealistic scale ceiling
A central team cannot grow forever. Ten domains is fine, fifty domains cracks.

Data mesh flips the ownership model: not central but federated.

The four principles of data mesh

Dehghani defined four principles that together make up a data mesh. Picking one or two without the rest is not a data mesh.

1. Domain-oriented ownership

Each business domain owns the data that belongs to its processes. Sales owns customer and order data, logistics owns shipment data, finance owns accounting records. They know the semantics, they carry the accountability.

2. Data as a product

Each domain does not build data for itself, but for consumers elsewhere in the organisation. That changes the mindset: you think about users, documentation, versioning, and SLAs. A data product has an owner, a clear interface, a data contract, and tooling that makes it easy to discover and use.

3. Self-serve platform

To make domains autonomous, they need a platform that takes the heavy lifting off their plate. No separate Kubernetes cluster per team, no separate governance tools. A central platform team provides the plumbing: storage, compute, pipelines, catalog, monitoring. Domains focus on content.

4. Federated computational governance

Domains are autonomous but not entirely free. Organisation-wide rules (privacy, security, naming conventions, interoperability) are defined centrally and enforced through tooling across every domain. Governance is federated: agreed together, checked automatically.

What is a data product?

A data product is a dataset plus everything around it that makes it easy to use.

• A description and schema, through a data contract.

• An SLA: how fresh, how available, how clean.

• An owner with contact information.

• Documentation covering semantics and usage examples.

• Observability: metrics, drift monitoring, incidents.

• Interfaces: a table, an API, a stream, a semantic model.

In Fabric a data product might be a lakehouse with a published semantic model, a well-documented catalog registration, and clear permissions.

When does data mesh fit, and when does it not?

Fits well when:

• Large organisations with many domains and clear domain boundaries.

• Mature data teams that already know the technical basics.

• Organisations where a central data team is structurally overloaded.

Usually does not fit when:

• Smaller organisations that can easily run on one warehouse team.

• Early-stage data teams: without base maturity, data mesh turns into chaos.

• Organisations without an engineering mindset in the domains. Without product thinking at the edges, it does not work.

Pitfalls

Data mesh as an excuse not to centralise
Some organisations label their chaos as data mesh. Four domains each curating their own spreadsheets is not a mesh, it is a sprawl. Mesh requires explicit principles, tooling, and governance.

No platform team to build on
Without a strong self-serve platform, domains have no foundation. Invest in the platform first, the mesh model second.

Underestimating governance
Federated governance sounds lightweight. In practice it is harder than central governance: every domain has to play along and rules have to be enforced automatically.

Semantic silos
If each domain keeps its own definition of customer or product without alignment, you get reports that contradict each other. Conformed dimensions and organisation-wide conventions remain necessary.

Hype train
Data mesh solves a specific scaling problem. For many organisations, a solid warehouse or lakehouse is still the right answer. Do not let hype pick your architecture for you.