Explainer
What is data mesh? The four principles, and when it fits
Data mesh moves ownership of analytical data to business domains, which publish data products on a shared self-serve platform under federated governance. The four principles, how it differs from a central data team, prerequisites and common failure modes.
Hemant Walchale
· 4 min read
Data mesh is a way of organising analytical data around the business rather than around a central data team. Each business domain owns its data and publishes it as data products; a central team provides a self-serve platform; and shared, automated governance keeps products secure and interoperable. Zhamak Dehghani introduced the idea in 2019 as an answer to a familiar problem: the central data team becomes a bottleneck, and the people who understand the data are not the people responsible for it.
The four principles
| Principle | What it means in practice |
|---|---|
| Domain-oriented ownership | The team that runs a business area (and its source systems) owns the analytical data from it, end to end |
| Data as a product | Each dataset others depend on has an owner, documentation, a contract, quality guarantees and users it serves |
| Self-serve data platform | A central platform team provides storage, compute, pipeline templates, catalog, access control and monitoring so domains can build without specialists |
| Federated computational governance | Standards (security, naming, interoperability, quality) are agreed jointly and enforced automatically by the platform, not by review boards |
Central data team vs data mesh
| Central data team | Data mesh | |
|---|---|---|
| Who builds pipelines | Central data engineers | Domain teams, using platform templates |
| Who owns data quality | The data team, often without business context | The domain that produces the data |
| Bottleneck | The central team’s backlog | Domain capacity and skills |
| Governance | Central policies, manual review | Shared standards, enforced by the platform |
| Best for | Small to mid-size organisations, few data producers | Large organisations with many domains and producers |
What a data product needs
A table in a shared schema is not a data product. At minimum, each product should have:
- A named owner in the domain, and a published contract (schema, meaning, freshness, quality checks). See data contracts for data leaders.
- Discoverability in a catalog, with descriptions and lineage.
- Access control that consumers can request through the platform.
- Service levels for freshness and availability, with monitoring that alerts the owner.
How platforms support it
On Databricks, Unity Catalog catalogs per domain plus Delta Sharing support domain ownership with central governance. Snowflake uses databases per domain, secure data sharing and its internal marketplace. Microsoft Fabric has domains for grouping workspaces by business area, with OneLake as the shared storage layer. The platform features help, but none of them creates owners.
When data mesh fails
- Tool-first: buying a “data mesh platform” without moving ownership to domains.
- No platform: asking domains to build pipelines from scratch, which recreates the skills bottleneck in every team.
- Governance as meetings: standards that rely on review boards rather than automated checks slow everything down.
- Too early: applying it in an organisation with a handful of data sources and one data team, where it mostly adds overhead.
A practical middle path is to adopt the parts that pay off at any size: clear ownership per dataset, contracts on critical data, a well-run platform, and governance enforced in code. Decentralise building only when the central team is truly the constraint.
The short version
Data mesh gives business domains ownership of their analytical data, published as data products with owners and contracts, on a self-serve platform, under governance enforced by the platform. It is an operating model, not a tool, and it pays off mainly in large organisations where a central data team has become the bottleneck. Our data platform engineering team helps design the platform side, and our data quality and governance service covers ownership, contracts and standards.
Related: what is a data lakehouse, data contracts for data leaders, what is Unity Catalog, what is data observability and what is reverse ETL.
Sources
- How to move beyond a monolithic data lake to a distributed data mesh, Zhamak Dehghani, martinfowler.com, 2019
- Data mesh principles and logical architecture, Zhamak Dehghani, martinfowler.com, 2020
Further reading from other practitioners
Not sure where your own platform stands? Take the free 3-minute data platform scorecard. Unfamiliar terms are explained in the data engineering glossary.