Data Fabric vs Data Mesh: Two Answers to the Same Problem

Data fabric and data mesh are answers to the same problem: a central data team cannot keep up with demand, so every request queues behind the last one and the business routes around the queue by building its own copies.

They answer it from opposite directions. Data fabric is a technical answer — a connected metadata and access layer that makes distributed data reachable and governed from one place, so the central team scales through automation. Data mesh is an organisational answer — domain teams own their data as products, with a self-serve platform underneath, so the central team stops being the bottleneck by no longer sitting in the path.

They are frequently presented as competitors. In practice most organisations that succeed with either end up with elements of both, and the useful question is which problem you have first.

The problem they both address

Recognisable in almost any large institution.

Data lives in twenty systems owned by different departments. A central data team is responsible for making it usable. Every new report requires that team to understand a domain they do not work in, build a pipeline, and maintain it forever. The backlog grows monotonically. Business units stop waiting and build their own extracts, which produces the four-versions-of-the-same-metric problem, which produces a governance programme, which does not fix the queue.

Both approaches accept that the central-team model does not scale. They disagree about what to do instead.

Data fabric

A fabric leaves ownership where it is and invests in a layer that spans everything: an active metadata catalog, automated discovery and classification, a federated query engine, and centrally enforced access policy.

The mechanism is automation. Instead of a person building a pipeline per request, metadata is harvested continuously, lineage is derived from code and query logs, sensitive data is classified by pattern, and access policy is applied in one place across many sources. The central team's capacity stops being the constraint because the work per new dataset drops sharply.

Where it fits. Estates with heavy regulation, a lot of legacy, and no realistic prospect of domain teams taking ownership. That describes most banks and state institutions in Azerbaijan, where the core banking system has one custodian team and the idea of a "domain team owning it as a product" does not map onto how the institution is staffed.

Where it fails. Fabric solves reachability, not meaning. A perfectly connected fabric over data nobody understands produces fast access to ambiguous numbers. It also concentrates load and responsibility on the platform team, which is a smaller queue rather than no queue.

The technical components are the ones covered in data virtualization and metadata management.

Data mesh

A mesh moves ownership. Each domain — retail lending, payments, risk — owns its data, publishes it as a data product with a defined interface, documented semantics, quality guarantees and a named owner, and is accountable for it in the same way it is accountable for its applications.

Four principles hold it together: domain ownership, data as a product, a self-serve platform that makes publishing cheap, and federated computational governance — global rules enforced automatically by the platform, local decisions made by domains.

Where it fits. Organisations with genuine engineering capability inside business domains, a culture that already treats internal services as products, and enough scale that central coordination is the dominant cost. Large technology-led companies, essentially.

Where it fails. Domains without engineering capacity cannot own data products, and telling them they now do produces neglected products with a name attached. The self-serve platform is also routinely underestimated: without it, mesh is just decentralisation, and decentralisation without a platform is how you get twenty incompatible data products and no way to join them.

The most common failure is adopting the vocabulary without the platform. An organisation that renames its extracts "data products" and assigns owners has performed a naming exercise.

Choosing between them

Four questions settle it faster than a strategy workshop.

Do your business domains have engineers? Not analysts — engineers who can build and operate a service. If no, mesh is not available to you yet, whatever the strategy deck says.

What is your dominant constraint — reach or meaning? If people cannot get to the data, fabric addresses that directly. If people can get to the data and do not trust or understand it, that is a semantics and ownership problem, which points to mesh principles.

How regulated are you? Heavy supervision pushes toward centrally enforced policy, which is easier in a fabric. Mesh can satisfy a regulator, but only with the computational governance part genuinely built — and that part is the one organisations skip.

How much legacy? Mesh assumes systems can be wrapped in product interfaces. A thirty-year-old core banking system with one custodian team resists that. Fabric reads it where it is.

For most Azerbaijani banks and ministries, the honest answer is fabric first, with selected mesh principles — named domain owners, published quality expectations, documented semantics — applied on top. That is not a compromise; it is the sequence that produces something in a year rather than a reorganisation in three.

The hybrid that actually works

What successful programmes converge on, described without the vocabulary.

Centralised: metadata, catalog, lineage, classification, access policy enforcement, the query engine, and the platform on which everything runs. These benefit from being one thing, and splitting them produces inconsistency that shows up in an audit.

Federated: definitions, quality rules, and ownership. The domain decides what active customer means and what quality level its data guarantees, because only the domain knows. The business glossary is where this lands.

Automated: harvesting, classification, lineage derivation, policy application. Anything a machine can do, so that human attention goes to judgement.

That arrangement takes fabric's technical layer and mesh's ownership model, which is what both were actually arguing for underneath the terminology.

What neither will do

Independent of choice, and worth saying plainly because both are sold as transformations.

Neither creates ownership where management has not assigned it. Neither settles a definition dispute. Neither cleans your data. Neither reduces the number of systems you run. And neither survives being run as a technology programme with no business sponsor — which is the single most reliable predictor of failure for both.

The architecture is perhaps a quarter of the outcome. The rest is scope discipline, ownership that has real time allocated, and definitions that survived an argument. Choosing the more fashionable term does not substitute for any of it.

Key points

• Same problem — the central data team cannot keep up. Fabric answers technically, mesh organisationally.
• Fabric: connected metadata, federated query, centrally enforced policy. Fits regulated, legacy-heavy estates. Solves reach, not meaning.
• Mesh: domain-owned data products on a self-serve platform. Requires engineers inside domains. Without the platform it is just decentralisation.
• Four questions decide it: engineering capacity in domains, reach versus meaning, regulatory weight, legacy burden.
• Most institutions here should build the fabric and apply mesh ownership principles on top — named owners, published quality, documented semantics.
• Neither creates ownership, settles definitions or cleans data. The architecture is about a quarter of the outcome.

We build the technical layer — Starburst for federated query, OvalEdge for catalog and governance — deployed on-premise. Related reading: data lakehouse architecture and what is data governance.