Data mesh

Overview

Data mesh, a concept introduced by Zhamak Dehghani, reframes data architecture around organizational ownership rather than centralized pipelines. In a traditional centralized model, one data team is responsible for ingesting, transforming, and serving data from every part of the business—which becomes a bottleneck as an organization grows, since that central team rarely has deep context on any one domain's data.

Data mesh proposes decentralizing that responsibility: each business domain (orders, marketing, inventory) owns its own data end to end, treats it as a product to be consumed by others, and is supported by shared, self-serve infrastructure rather than a central team doing the work on their behalf.

The four principles

Data mesh is typically defined by four interrelated principles:

1. Domain-oriented ownership — the team closest to a data source (the domain that produces it) owns its data pipelines and quality, rather than handing it off to a central data team.
2. Data as a product — each domain treats its data outputs as products with defined interfaces, documentation, SLAs, and a responsibility to serve other teams well, not just as a byproduct of their application.
3. Self-serve data platform — a shared platform provides the infrastructure (storage, compute, orchestration, cataloging) that domain teams use to build and serve their data products, so each domain doesn't need to reinvent infrastructure.
4. Federated computational governance — global standards (security, interoperability, compliance) are agreed centrally, but enforcement is automated and embedded in the platform, rather than requiring central approval for every change.

Why organizations adopt it

Data mesh is generally considered by larger organizations where a single centralized data team has become a bottleneck—every new pipeline or schema change requires going through an overloaded team with limited domain context, slowing everyone down. Distributing ownership to domain teams who understand their own data best can reduce that bottleneck, at the cost of needing more mature platform tooling and governance automation to keep the decentralized parts consistent.

Data mesh and query engines

Data mesh is an organizational and architectural pattern, not a specific product, so it doesn't mandate any particular query engine. In practice, a mesh's domain teams might use different tools suited to their needs—one domain's data product might be served from a cloud data warehouse, another from a lakehouse, and a smaller domain might use something as lightweight as DuckDB to build and serve its own data product without needing a shared cluster.

Data mesh vs. data fabric

Data mesh and data fabric are often mentioned together but solve different problems: mesh is primarily an organizational/ownership model, while data fabric is primarily a technical integration layer for connecting data across disparate systems, often using automation and metadata rather than reorganizing teams.