Biblioteca de conceptos

Data Mesh

An organizational and architectural pattern that distributes data ownership to domain teams, treats data as a product, and federates governance — replacing the central data team with a platform-and-policy model.

What it is

Data mesh is a four-principle pattern proposed by Zhamak Dehghani in 2019:

  1. Domain ownership — domain teams own their data, end-to-end.
  2. Data as a product — domain data is treated as a product with users, SLAs, and a roadmap.
  3. Self-serve data platform — a central platform team makes domain ownership feasible without rebuilding infrastructure in each domain.
  4. Federated computational governance — global policies are encoded as code and enforced at the platform layer.

Mesh is more an operating model than a technology choice. The platforms underneath a mesh look very similar to the platforms underneath a non-mesh organization. The difference is who owns what.

Why it matters

Centralized data teams hit a scaling ceiling around 25 people and a credibility ceiling around 40. Past those points, the bottleneck is no longer technology but cognitive load — the central team cannot understand every domain deeply enough to model it correctly, and the domains cannot get their requests prioritized fast enough. The result is a backlog culture and quietly declining quality.

Data mesh is the structural answer: stop trying to scale the central team and instead push ownership outward, while building a platform that makes that ownership feasible. Done well, the central team becomes a leverage multiplier rather than a bottleneck.

Done poorly, mesh becomes the worst of both worlds — domain teams that don’t know how to own data, no central authority to enforce quality, and a platform that nobody uses because the policies are theoretical.

How it works

The four principles in practice

Domain ownership. Each business domain (sales, supply chain, product, finance) owns its data products. Ownership means: the domain team builds, maintains, monitors, and deprecates its own data products, and is accountable for their quality.

Data as a product. Each data product has a designated owner, a public interface (the data contract), an SLA, documentation, and a versioning policy. Users of the product (other domains, BI, ML, agents) consume it through the contracted interface, not by reaching into the source system.

Self-serve platform. The central platform team builds: ingestion templates, transformation patterns, a unified storage layer, a catalog, a governance toolkit, and observability. Domains use this platform; they do not build their own.

Federated governance. Global policies (PII handling, data classification, access patterns, naming conventions) are defined centrally but encoded as automated checks running at the platform layer. Domains cannot opt out, but they also do not have to manually enforce.

When to adopt

Mesh is the right answer when:

  • Your organization has more than ~5 reasonably autonomous business domains
  • Your central data team is past 25 people
  • You have at least one domain mature enough to own a data product credibly
  • Leadership is willing to invest in a platform team for 12+ months before mesh outcomes appear

Mesh is the wrong answer when:

  • The organization is small enough that one team can serve everyone
  • Domains do not have engineering capability or appetite to own data
  • The central team is rebuilding the platform anyway (do that first)
  • Leadership wants quick wins (mesh produces no quick wins)

Vendor comparison

Data mesh is platform-agnostic in principle, but several vendors have built explicit support for the pattern.

AspectDatabricks Lakehouse + Unity CatalogSnowflake (with Horizon)Confluent (Kafka-centric)Microsoft Fabric
Domain isolationCatalogs and schemas with grantsDatabases, schemas, RBACTopic ownership, RBACWorkspaces
Product publishingUnity Catalog + Delta SharingSnowflake Native Apps + MarketplaceSchema Registry + Stream CatalogOneLake + shortcuts
GovernanceUnity Catalog (lineage, PII, access)Horizon (DCM, lineage, access)Stream GovernancePurview integration
Self-serveDBSQL, Workflows, MLflowNotebooks, dbt integration, dynamic tablesksqlDB, Connect, Stream DesignerPipelines, Notebooks, KQL
Cross-domain sharingDelta Sharing (open protocol)Secure Data Sharing (proprietary)Topics + ACLsOneLake shortcuts
Best forHeterogeneous workloads (SQL+ML+streaming)SQL-centric meshEvent-driven meshMicrosoft-shop mesh

Databricks + Unity Catalog. The strongest current platform for implementing mesh end-to-end. Unity Catalog’s hierarchy (metastore → catalog → schema → table) maps cleanly to platform → domain → product → asset. Delta Sharing as an open protocol means cross-domain sharing does not require a vendor lock-in conversation. ML and streaming live on the same platform.

Snowflake + Horizon. Excellent for SQL-centric organizations. Native Apps and Secure Data Sharing make cross-domain product publishing elegant. The trade-off is heavier ML and streaming workloads — possible but not native.

Confluent. The mesh-of-events pattern. Topics become data products; the schema registry becomes the contract; consumers subscribe. Powerful when the organization is event-driven; less natural when most consumers want SQL.

Microsoft Fabric. The right answer when the organization is deep in Microsoft. OneLake’s shortcut model is conceptually similar to Delta Sharing. Worth evaluating but earlier on the maturity curve than Databricks or Snowflake.

Yoann’s take

Data mesh is the right destination for any organization with five or more domains and a central data team that has hit its scaling ceiling. It is also the wrong starting point for almost everyone else. In my engagements, I almost always implement the mesh principles incrementally — domain ownership first, then data-as-a-product, then platform investment, then governance — over 18 to 36 months. Calling it a “mesh transformation” on day one is the surest way to fail at it. Build the discipline; the label will earn itself.

— Yoann


External references

  • Data Mesh: Delivering Data-Driven Value at Scale — Zhamak Dehghani, O’Reilly
  • How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh — Dehghani, martinfowler.com (2019)