Lately, no conversation about data architecture seems to end without two terms coming up: data mesh and data fabric. Both promise to solve the same underlying pain —that a company’s data is scattered, hard to find and not entirely trusted— but they tackle it from very different angles. And, as often happens with buzzwords, they are frequently used as synonyms when they are not.
In this article we clarify what each one is, how they really differ, and how to decide which fits your organisation.
Why everyone is talking about data architecture in 2022
The reason is simple: the volume and variety of data have grown faster than companies’ ability to organise it. The classic centralised data warehouse and the single data team that manages everything start to fall short when each business area has its own sources, its own needs and its own deadlines.
Out of that bottleneck come two answers. One is organisational; the other is technological.
What Data Mesh is
Data mesh is, above all, an organisational shift. The concept was coined by Zhamak Dehghani (Thoughtworks) and starts from a provocative idea: stop treating data as a by-product of a central team and start treating it as a first-class product, owned by whoever understands it best.
It rests on four principles:
- Ownership by business domains. Each domain (sales, logistics, marketing) is responsible for its own data, instead of depending on a single central team.
- Data as a product. A domain does not just generate data: it publishes it with quality, documentation and clear “service agreements”, with the consumer in mind.
- Self-service platform. A common infrastructure lets each domain publish and consume data without reinventing the wheel.
- Federated governance. Common rules (security, definitions, quality) applied in a coordinated way, not imposed from a silo.
In short, data mesh decentralises: it distributes responsibility for data across the teams that know it best.
What Data Fabric is
Data fabric is, above all, a technological approach. Championed strongly by Gartner, it proposes an intelligent integration layer that stretches across all your data sources —wherever they live: on-premise, in the cloud, across different applications— and connects them coherently.
Its key ingredient is active metadata: the data fabric analyses how data is used, what relationships exist between datasets and where everything lives, then uses that information (with the help of machine learning) to automate integration, suggest connections and simplify access.
Put differently, a data fabric does not force you to move or reorganise your data: it builds a layer on top that unifies it virtually and makes finding and combining it far easier.
How they differ
Here is the point many articles gloss over:
- Data mesh is an organisational and cultural change. It answers the question “who is responsible for the data?”. Its central unit is the business domain and the people in it.
- Data fabric is a technological change. It answers “how do I technically connect and integrate my data?”. Its central unit is metadata and automation.
They are not rivals competing for the same job. In fact, they can coexist: an organisation can adopt the data mesh philosophy of domains and, at the same time, rely on a data fabric layer to technically integrate those domains.
A useful way to remember it: data mesh decides who does what; data fabric decides how everything connects.
Which one to choose for your organisation
There is no universal answer, but there are some signals:
- Lean towards data mesh if your main problem is organisational: an overloaded central team, business areas waiting weeks for their data, and no clear ownership of quality. It requires maturity and business teams willing to “own” their data.
- Lean towards data fabric if your problem is technical: data spread across many different systems, fragile integrations, and difficulty getting a unified view. It is a more tool-driven approach and less disruptive at the people level.
- Consider both if you are a large, complex organisation: a culture of domains plus an intelligent integration layer complement each other well.
Whichever path you take, both share one non-negotiable prerequisite: clear definitions and governance. No architecture rescues data that nobody knows the meaning of. That is why both fit naturally within a well-designed Modern Data Stack.
Start with the diagnosis, not the label
The most common mistake is choosing an architecture by its fashionable name before understanding the real problem. The first step is to diagnose: is your bottleneck about people or about technology?
At Digital Fox Data we help answer that question and design a data architecture that fits your reality, not the latest trend, through our Business Intelligence consultancy. If you want to get your data strategy in order before investing in tools, let’s talk.