Data Mesh vs Data Fabric: What Each Solves, and When Neither Fits
Data mesh is an answer to an ownership problem. Data fabric is an answer to an integration and metadata problem. The first step is to establish which problem the organisation has, because it may be neither.
Data mesh and data fabric are both proposed as target architectures, sometimes in the same meeting and as alternatives. They are not alternatives in the way two databases are. A data mesh changes who is responsible for analytical data: it moves ownership from a central team to the business domains that produce the data. A data fabric changes how data scattered across systems is found, connected and accessed: it adds a metadata-driven layer over what already exists, without requiring the data to move.
One is an organisational answer and the other a technical one. An organisation can adopt either, both or neither, and the decision turns on a prior question that both proposals can skip: what is the constraint? This article describes what each approach claims, what each assumes is already in place, what the published evidence shows, and the organisations for which neither is the right place to start.
Mesh is an answer about ownership
Data mesh has an identifiable origin. Zhamak Dehghani set it out in two articles, in 2019 and 2020, and the argument begins with a diagnosis of central data teams. She describes them as “a group of hyper-specialized data engineers siloed from the operational units of the organization”1: people asked to supply trustworthy data from source systems they do not run, to users whose purposes they do not know.
Her remedy is to move the responsibility. In her words, “Data mesh, at core, is founded in decentralization and distribution of responsibility to people who are closest to the data”2, and the boundaries follow the business: “Data mesh follows the seams of organizational units as the axis of decomposition”2. The team that runs a business capability also provides the analytical data about it.
Three further principles exist to make that first one workable. Domains must treat what they publish as a product with users. A shared platform must remove the specialist infrastructure work, because, as she puts it, “the skills needed to provision this infrastructure are specialized and would be difficult to replicate in each domain”2. And a federated governance group has to set the few rules that apply everywhere, a task she describes as “maintaining an equilibrium between centralization and decentralization”2.
Nothing in this prescribes a technology. Dehghani offers the second article as “a simple and technology-agnostic model”2. A product sold as a data mesh is, at most, the platform a mesh would run on.
Fabric is an answer about metadata and integration
Data fabric has no equivalent founding text, and that affects how far any definition can be trusted. The term comes from industry analysts and vendors. The analyst definitions sit behind paywalls or could not be retrieved for this article, so the description here rests on a vendor’s public explanation and is labelled as such.
IBM, which sells products in this category, describes a data fabric as follows: “It is not a piece of software, but rather a design approach that creates a unified view of data across an organization’s on-premises and multicloud environments”3. The same page states the central promise: “organizations don’t have to move distributed data to a single location or data store, nor do they have to take a completely decentralized approach”3.
Two mechanisms carry that promise. The first is virtualisation: “Data virtualization makes data accessible without physically moving it”3. The second is metadata that is collected and analysed continuously, which the page calls active metadata and says “uses semantic knowledge graphs and AI/ML technologies to continuously analyze metadata”3.
Read plainly, a fabric is a layer of cataloguing, integration and access control placed over existing stores, with automation doing work that people would otherwise do by hand. It says nothing about who owns the data. That is why the vendor can state that “Data fabrics coexist with data meshes, and often enhance their functionality”3: the two operate on different parts of the problem.
The caution is about evidence. The claims for mesh can be checked against an originating text and against independent studies. The claims for fabric, in the sources available here, come from an organisation with something to sell. That does not make them wrong. It means a buyer should ask for the mechanism behind each claim and test it on their own estate.
The data product, which both depend on
Both approaches lean on the idea of a data product, and it is worth being exact about it. Dehghani’s requirement is that “domain data teams must apply product thinking with similar rigor to the datasets that they provide”1. She lists six qualities a dataset needs before it counts: discoverable, addressable, trustworthy and truthful, self-describing, interoperable, and secure1. The first is stated without qualification: “A data product must be easily discoverable”1.
A data product in this sense is a dataset with a named owner, a stated purpose, a described structure, a known level of quality and a stable way to get at it. The owner is measured on whether people can use it; Dehghani names “data quality, decreased lead time of data consumption, and in general data user satisfaction” as the measures2.
This is the most transferable idea in the whole debate, and it does not require a mesh. A central team can publish data products. So can a single domain, as an experiment. The Data Product Canvas sets out the elements on one page: owner, consumers, contents, quality commitments and interface. Who is entitled to hold the owner’s role is a governance question, covered in data owners, stewards and custodians.
What each assumes is already true
Each approach works only where certain conditions hold. The conditions are where the decision is made.
Preconditions each approach assumes
| Data mesh | Data fabric | |
|---|---|---|
| The problem it addresses | A central data team has become the bottleneck and lacks domain knowledge | Data is spread across many stores and cannot be found, connected or governed consistently |
| Organisational precondition | Business domains with their own teams, able to take on data work | None specific; ownership stays where it is |
| Technical precondition | A self-serve platform that domains can use without specialists | Metadata of sufficient quality for automation to act on |
| Governance precondition | Mature enough to set and enforce shared rules across independent teams | Policies that can be expressed and applied centrally |
| What changes most | Roles, accountability and funding | Tooling and integration |
| Main risk | Domains treat data work as an unfunded extra | The layer hides, without resolving, unclear ownership and poor source data |
The mesh column is supported by the academic sources discussed below. The fabric column is DII’s reading of what the described mechanisms require, and should be treated as analysis.
What the evidence from adopters shows
Two academic studies give an independent view of mesh. Neither is a large survey and both say so.
A systematic review led from Tilburg University analysed 114 practitioner publications on data mesh. Its conclusion on fit is direct: a data mesh “is not a one-size-fits-all approach for data management”4. It identifies four situations in which the approach may not suit. An organisation without independent domain teams, for which the review’s wording is that it “does not have multiple teams who can make data products independently”4. One with weak governance, since the approach “may not be suitable for organizations with a low level of maturity in data governance”4. One without platform engineers, because “Building a self-serve data platform can be impractical for organizations without experienced data platform engineers”4. And one with little analytical demand, where “the cost and risks of transitioning a data mesh would far outweigh the benefits”4.
A second study interviewed people who had implemented one. Its authors, three of the four at IBM, conducted “15 semi-structured interviews with industry experts” and report that “organizations have difficulties with the transition toward federated data governance associated with the data mesh concept, the shift of responsibility for the development, provision, and maintenance of data products, and the comprehension of the overall concept”5.
The three difficulties are worth restating in plain terms. Shared rules across independent teams are hard to agree. Domains do not readily accept data work as theirs. And people inside the organisation do not have a common understanding of what is being attempted. None is a technology problem, and none is solved by buying a platform.
There is no comparable independent evidence on data fabric in the sources read for this article. That absence is a finding about the evidence. It is not a finding about fabric.
When neither is the right starting point
For some organisations the honest answer to “mesh or fabric?” is that the question has arrived early. DII’s view is that neither is a sensible first move in four situations.
The central team is not the constraint. If requests are met in reasonable time and the complaints are about data quality or missing definitions, redistributing ownership addresses a problem the organisation does not have.
There are few sources and few uses. A small estate can be understood by a small team. The review cited above makes the same point about cost and benefit4.
Ownership is undefined. A mesh needs owners to hand responsibility to, and a fabric needs owners to say what its policies should be. Where nobody answers for a dataset today, that is the work to do first.
The basics are unreliable. If pipelines fail without notice and nobody can say where a figure came from, a new architectural layer will be built on the same weakness.
In each case the better starting point is smaller: name owners for the datasets that matter most, publish two or three of them as data products with stated quality, and catalogue what exists. Those steps are worth taking in their own right, and they are also the preconditions that either approach will later need.
A way to decide
The questions below are in order. Each answer narrows the choice.
- What is the constraint? Write it as an observable problem: time to obtain a new dataset, inability to find data, inconsistent definitions, or cost of integration. If it cannot be stated, stop here.
- Is it about who does the work, or about connecting what exists? The first points towards mesh. The second points towards fabric-style tooling.
- Do the preconditions hold? Use the table. Where they do not, the preconditions are the programme.
- What is the smallest test? One domain publishing one data product, or one catalogue connected to three sources, will show more than a target-state diagram.
- What is being given up? A mesh gives up central control of modelling. A fabric adds a layer that must be run and paid for. Record the trade.
The answers belong in a decision record, with the options that were rejected; architecture decision records for data teams describes the practice, and the Data Architecture Decision Framework provides a structure for it.
Neither approach replaces the storage and processing decisions underneath it. A mesh can sit on a warehouse, a lake or a lakehouse, a choice compared in data warehouse, data lake or lakehouse, and both are answers to one of the seven questions described in modern data architecture: the layers, patterns and decisions that matter. Where a mesh is chosen, the shared platform it depends on has to be funded and run as a service to the domains, which is the subject of running a data platform as a product.
Sources
- Dehghani, Z. How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh (martinfowler.com). 20 May 2019.
- Dehghani, Z. Data Mesh Principles and Logical Architecture (martinfowler.com). 3 December 2020.
- IBM. What is a data fabric? (IBM Think).
- Goedegebuure, A., Kumara, I., Driessen, S., van den Heuvel, W.-J., Monsieur, G., Tamburri, D. A. and Di Nucci, D. Data Mesh: A Systematic Gray Literature Review (arXiv:2304.01062, version 3). 7 August 2024.
- Bode, J., Kühl, N., Kreuzberger, D. and Hirschl, S. Towards Avoiding the Data Mess: Industry Insights from Data Mesh Implementations (arXiv:2302.01713, version 4). 6 June 2024.
This article is general professional information. It is not legal or regulatory advice.