A data mesh is an organizational approach to analytics in which the teams closest to the data own it. Instead of routing everything through one central data team, each domain — orders, payments, logistics — publishes its own well-defined datasets for the rest of the company to use.
To be clear about the category: a data mesh is not a product you can buy or a system you install. It’s an organizational design — a decision about who owns data and who is accountable for its quality — that you implement on top of whatever data warehouse, lake, or pipelines you already run. Vendors sell tools that support the pattern; none of them are the pattern.
The problem it responds to
The centralized model has a predictable failure mode at scale. One data team sits between every source system and every consumer, building and maintaining every data pipeline. Requests queue up. The team maintains models for domains it doesn’t deeply understand, so subtle errors creep in — and when the payments schema changes, the people who changed it aren’t the people whose pipelines break. The bottleneck isn’t a tooling problem, which is why buying faster tools doesn’t fix it.
The four principles
Data mesh, as articulated by Zhamak Dehghani, rests on four ideas:
- Domain ownership. The team that generates the data — and understands what it means — owns its analytical form too.
- Data as a product. A domain’s published dataset is treated like a product: it has an owner, documentation, quality standards, and consumers whose trust matters. Data contracts are the natural interface here.
- Self-serve platform. A platform team provides shared infrastructure — storage, pipeline tooling, orchestration — so each domain doesn’t rebuild the plumbing.
- Federated governance. Global standards (naming, privacy, security, interoperability) are set centrally; everything else is decided in the domain.
In practice the published datasets look a lot like well-governed data marts, and cross-domain consistency still needs shared definitions — a semantic layer problem the mesh doesn’t make disappear.
The honest trade-offs
Data mesh solves a scaling problem, and if you don’t have that problem, it’s mostly overhead. A twenty-person company with one data team does not need federated governance; it needs the data team. The costs are real: every domain now needs data skills (or borrows them thinly), platform investment comes before payoff, and decentralization without discipline yields the old chaos with better branding — duplicate datasets, inconsistent definitions, and no one sure which “orders” table to trust.
The consumption end changes least of all. Whether datasets are published by one team or twelve, people still need to find them and query them — and a self-serve BI tool like Metabase, connected to the domains’ published datasets, is one way the “product” half of data-as-a-product actually reaches its users.
Related terms
Further reading
Put it to work
- Data freshness — Metric
- ETL dashboard — Dashboard
- Data lake dashboard — Dashboard
