Kindly fill up the following to try out our sandbox experience. We will get back to you at the earliest.
Data mesh gives each business domain ownership of its own data products. The definition, the 2019 origin, how it compares, and when it is the wrong choice.
Updated on
.jpg)
A data mesh is a way of organizing analytical data in which each business domain owns, publishes and supports its own data as a product, on shared self serve infrastructure, under one set of rules that every domain has agreed to follow.
That single sentence contains the whole idea. Everything else is detail about how it is built. The word mesh describes the shape: instead of every pipeline running into one central warehouse owned by one central team, you get many domains publishing to each other, connected by shared standards rather than by shared staff.
Three things change on the day a mesh starts working, and they are the three worth checking if you want to know whether an organization really has one:
You will also see the term written as one word, datamesh. It means the same thing. The two spellings are used interchangeably in job adverts and conference talks, and neither is more correct than the other.
Data mesh was introduced by Zhamak Dehghani, then a principal technology consultant at Thoughtworks, in an essay titled "How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh", published on martinfowler.com on 20 May 2019. The problem she was describing was organizational rather than technical: central data teams had become the bottleneck between the people who produced data and the people who needed it, and adding more engineers to the centre made the queue longer rather than shorter.
The four principles that people now recite came later, in a second essay called "Data Mesh Principles and Logical Architecture", published on 3 December 2020. That is a useful date to know, because a lot of material written in between describes a mesh without the federated governance principle, which is the part that stops a mesh becoming a set of disconnected silos.
Two things are worth taking from the history. The idea began as a critique of a centralized operating model, not as a technology proposal, which is why no vendor can sell you one. And it was written for organizations large enough to have a real bottleneck in the first place, which is the single most useful filter when deciding whether it applies to you.
A data mesh treats data as a product and runs a shared governance model across the domains that produce it. Domain experts handle their own data, which is what keeps it accurate and available, and the arrangement makes data management faster and more flexible than a single central queue.
The phrase "data as a product" is the one most often repeated and least often defined. In practice it means a published dataset carries the same things a software product carries: a named owner, documentation that says what each field means, a stable interface that does not change without notice, a stated quality promise, a route for consumers to report problems, and a deprecation policy for when it is retired. A table dropped into a shared schema with no owner and no documentation is not a data product, whatever the project plan calls it.
The four principles are the definition of a data mesh rather than a build sheet. Here is what each one asserts and what it changes in day to day work.
| Principle | What it asserts | What changes in practice |
|---|---|---|
| 1. Domain oriented ownership | Analytical data belongs to the business domain that generates it, not to a central team | The domain team gains a data engineering role and the central team stops writing other people's pipelines |
| 2. Data as a product | A published dataset is a product with a named owner, documentation and a quality promise | Consumers get a contract to rely on, and a route to complain when it is broken |
| 3. Self serve data platform | A platform team supplies the storage, pipelines, catalog and access controls every domain needs, as a service | Domains publish without filing tickets, and the platform team stops being a queue |
| 4. Federated computational governance | Policies are agreed centrally and enforced automatically inside the platform | Rules are written once and applied by the platform, rather than reviewed by hand per project |
That table is as far as this article goes on the principles, because each one carries an architecture behind it that deserves proper room. Our guide to data mesh architecture covers the layers, the platform interfaces and the order to build them in.
Most of the confusion around data mesh comes from five mistaken assumptions. Ruling them out saves more time than any amount of further definition.
A data mesh works differently from the older approaches such as a lake or a warehouse. It uses a distributed model in which each area looks after its own data, which is what makes it flexible and lets a business act on data faster. The table below sets the five common approaches side by side on the questions that actually separate them.
| Approach | Who owns the data | What it is good at | Where it struggles |
|---|---|---|---|
| Data mesh | Each business domain, with a named owner per data product | Removing a central bottleneck in an organization with many independent domains | Small organizations, where the coordination cost exceeds the bottleneck it removes |
| Data warehouse | One central data team | A single agreed version of a business figure, and reporting that has to be defended | Throughput, because every new request joins one queue |
| Data lake | One central platform team, in practice often nobody | Storing large volumes of raw and semi structured data cheaply | Trust, because raw data with no owner and no documentation is hard to rely on |
| Lakehouse | One central platform team | Combining lake storage economics with warehouse style tables and transactions | Ownership, which it does not address at all, since it is a storage design |
| Data fabric | One central team operating the integration layer | Unified access across systems you cannot or will not consolidate | Accountability, because unified access does not tell you who is responsible for quality |
A warehouse centralizes both the data and the responsibility for it, which is exactly what makes it good at producing one defensible number. A mesh keeps the responsibility with the domains. If your organization needs one agreed version of a figure that a regulator or an auditor will question, a warehouse is often still the better answer, and a mesh does not remove that need. Many organizations run a mesh for domain analytics and keep a governed warehouse for reported figures.
A lake is a storage decision and a mesh is an ownership decision, so the two are not really alternatives. The reason they get compared is that the failure mode of a lake, large volumes of data that nobody owns and nobody documents, is precisely what a mesh is designed to prevent. A mesh built on lake storage is common. A lake without domain ownership is the thing the original 2019 essay was arguing against.
The shortest distinction is that a fabric changes how data is accessed and a mesh changes who is accountable for it. A fabric can be delivered by a central team and largely invisible to the business; a mesh cannot, because it requires domain teams to take on work they did not previously do. We set the two out in full, with a comparison table and a decision rule, in data mesh vs data fabric.
The gap between the theory and a working mesh is usually the question of what a domain hands over. Take a payments domain as the example. Under a central model it hands raw transaction tables to a data team and the work stops there. Under a mesh it publishes a data product, and a data product is a set of artefacts, not a table.
| What the domain publishes | What it contains | Who signs it |
|---|---|---|
| The dataset itself | The tables or the stream, with a stable name and a stable location | The domain data owner |
| A data contract | The schema, the update frequency, and what counts as late | The domain data owner, agreed with the main consumers |
| Documentation | What each field means, in business language, and what it must not be used for | The domain subject matter expert |
| Quality checks and their results | The tests that run on every load, and the visible pass or fail history behind them | The domain data owner |
| Lineage | Where the data came from and which downstream reports depend on it | Produced by the platform, not written by hand |
| An owner and a route to reach them | A named person and an on call channel, not a shared inbox | The domain lead |
A useful test of whether a mesh is real: pick any dataset that a business report depends on and ask for those six things. If four or more are missing, what exists is a set of shared tables with a mesh vocabulary layered over it.
A data contract that nobody measures is a wish. Observability is the mechanism that turns the promise a domain publishes into something a consumer can verify, and in a mesh it has to work per data product rather than per warehouse, because there is no single central team watching everything.
Four signals cover most of what goes wrong, and every published data product should report all four:
The fourth is the one that separates a mesh from a set of independent teams. When ownership is distributed, a broken table in one domain surfaces as a wrong number in another domain's report, and column level data lineage is what lets the second team find the first without a meeting. The mechanics of the other three signals, and the difference between monitoring an input and monitoring an output, are covered in our guide to data observability.
Federation applies to the reporting as well as the data. Each domain watches its own products, and the platform team sees every domain in one view, which is how a governance group can tell whether the standards it agreed are actually being met.
Adopting a mesh is a combination of technical and cultural change, and it needs planning, agreement across teams, and a clear link to what the business is trying to do. Six moves have to happen, and none of them is optional. They are set out here as the cost of adoption rather than as a build guide, because the point of this section is to let you price the decision before you make it. The full sequence, with the architecture behind each move, is in our guide to data mesh architecture.
| The move | What it involves | What it costs you |
|---|---|---|
| 1. Mark the domains and the data products | Map the business processes and identify which areas generate and consume data, then break the silos and distribute ownership across them | Weeks of workshops, and an argument about who owns the shared dimensions such as customer and product |
| 2. Agree domain driven design principles per domain | Define the business context, the language and the boundaries of each domain, and the data products each will publish | Modeling time from people who are not data engineers, and a shared vocabulary that has to be maintained |
| 3. Build a data platform team | Stand up the infrastructure, the pipelines, the catalog and the interfaces every domain publishes through | A permanent team, and the discipline to keep it a service rather than a queue |
| 4. Define and implement federated governance | Set the quality standards, the security policies and the privacy rules that apply to every domain, and enforce them in the platform | A governance group with real authority, and automation, since manual review will not scale across domains |
| 5. Run the mesh itself | Modular services and products designed to interoperate, so teams work independently and still share data | Ongoing engineering effort in every domain, not only in the centre |
| 6. Change how the teams work | Clear channels between domains, shared incentives, and rewarding teams for what their data products do for other people | The slowest and most commonly underestimated part, usually measured in quarters |
The second move is the one teams most often rush. If you want a longer treatment of how domains and data products are defined, this article on data domains and data products is a reasonable starting point.
A mesh can be built on several combinations of technology, and the original set commonly named includes containerisation, microservices, event driven architecture, domain driven design frameworks and data mesh platforms. That list describes the plumbing rather than the decision. What matters when you are choosing is which of the five layers below you already have and which you are missing, because a gap in any one of them shows up later as a data product nobody trusts.
| Layer | What it does in a mesh | What breaks without it |
|---|---|---|
| 1. Storage and compute | Holds the data and runs the transformations. Usually the warehouse or lakehouse you already run | Nothing new. This layer rarely changes when a mesh is adopted |
| 2. Catalog and discovery | Lets a consumer in one domain find and understand a product published by another | Domains cannot find each other's data, so they copy it, and you get the silos back |
| 3. Lineage | Records where each product came from and what depends on it, across domain boundaries | A break in one domain becomes an unexplained number in another, with no way to trace it |
| 4. Quality and observability | Tests each product against its contract and publishes the results | The data contracts become claims nobody can check |
| 5. Federated policy and access | Applies the agreed access, privacy and retention rules automatically inside the platform | Governance turns into a manual review queue, which is the bottleneck the mesh was meant to remove |
Layers two, three and four are where most organizations find the gap, because a central warehouse rarely needed them: when one team owned everything, discovery and lineage lived in that team's heads. Decube covers those three in one platform, with data discovery, column level lineage and quality monitoring sitting on top of the warehouse or lakehouse you already run, plus the policy layer a federated model needs. Our data governance platform page sets out how each part works and what it connects to.
The benefits below are real, and every one of them is conditional. Each is paired here with the condition that has to hold before an organization sees it.
Distributing ownership across teams and domains tends to improve quality, because each team has a reason to make its own products meet a standard and be fit for use. Domain driven design helps here too, since products defined against business objectives end up reflecting what their users actually need. The condition: quality improves only where a domain has someone accountable for it. Distributing ownership to a team with no data skills distributes the problem, not the solution.
Older approaches struggle to keep pace with change and to scale as demand grows. A mesh is designed to scale by adding domains rather than by adding people to a central team, which is what lets an organization respond faster and support new sources and use cases. The condition: this only pays off past the point where the central queue is genuinely the constraint. Below that point you are adding coordination to a system that was not blocked.
A mesh pushes teams towards outcomes rather than outputs, because they are building products other teams consume rather than filling tickets. That tends to align data work with what the business is trying to achieve and gets teams pulling in the same direction. The condition: someone has to measure whether a data product is used. Products nobody consumes are the most common form of waste in a young mesh.
Traditional data management can be expensive, with dedicated teams and infrastructure carrying the whole load. A mesh spreads that load across domains and, over time, reduces what the centre has to fund. The honest version: total cost usually rises before it falls. Every domain has to staff a role the central team used to hold, and for a period you are paying for both. Budget for the overlap or the program stalls halfway.
The model extends naturally to work that depends on many independent data sources, including machine learning and AI systems that consume data from across a business. The condition is the same as everywhere else: a model trained on a data product with no owner and no quality history inherits every problem in it, and distributing ownership without distributing accountability makes that harder to spot rather than easier.
A mesh is difficult to adopt, particularly in organizations used to a central model. The recurring problems are cultural resistance, technical complexity, and the ongoing governance and maintenance the model requires. Clear communication between teams, real training and support, and a governance framework that makes ownership explicit are what address them. Four specific failures are worth naming, because they are the ones that appear in the second year rather than the first.
| Challenge | What it looks like in practice | What addresses it |
|---|---|---|
| Cultural resistance | Domain teams treat data work as someone else's job and quietly keep filing tickets with the central team | Make the data product a named responsibility of the domain lead, not an extra task for whoever has time |
| Technical complexity | Every domain solves publishing, testing and access differently, and the platform becomes five platforms | The platform team owns the interfaces. Domains choose what to publish, not how to publish it |
| Duplicate data products | Three domains publish their own version of customer, and the numbers disagree | Assign the shared dimensions to a single domain before anything else is published, and put the rest in the catalog so duplication is visible |
| Contracts nobody enforces | Data contracts are written, then a schema changes without notice and a downstream report breaks | Enforce the contract in the platform as an automated check on every load, and treat a breach the way an outage is treated |
This is the section most articles on the subject leave out. A data mesh solves one specific problem, a central data team that has become the constraint on everything, and if that is not your problem it will add cost and coordination without returning anything. Run these four tests before committing. Failing any one of them is a reason to stop.
Two other situations call for a different answer regardless of how those tests go. Where the requirement is one agreed version of a figure, a governed warehouse remains the better fit, and where the requirement is processing events as they arrive, an event driven architecture fits better than either. A mesh is not the only approach to managing data and it is not a one size fits all solution; organizations have to shape it around their own needs and objectives.
Regulated businesses have a further constraint worth stating plainly. Supervisors such as OJK in Indonesia, APRA in Australia, MAS in Singapore and the state insurance regulators in the United States expect a named accountable owner behind a reported figure. Federation is compatible with that, but only if every regulated data product has one owner rather than a committee. If a domain cannot supply that name, do not federate that domain.
Data mesh has travelled a long way from a single essay in May 2019 to a standard entry on the definition pages of every large cloud vendor. What has not changed is the condition attached to it. Conventional centralized approaches stop working at a certain size, and a mesh is one answer to that, but it asks an organization to staff data ownership in places that have never had it.
The open question is therefore not technical. Tooling for catalogs, lineage, quality and federated policy is mature enough to support a mesh today. Whether domain teams can be staffed and held to a published promise is the part that decides whether a program works, and it is the part that no purchase can settle for you.
If the four tests above came out in favour and the gap is in the middle layers, catalog, lineage and quality, that is the part Decube is built for. You can book a demo of the Decube platform and see how a data product is catalogd, traced and monitored before you commit a domain to publishing one.
Image credit: Photo by Alina Grubnyak on Unsplash.
A data mesh is a way of organizing analytical data in which each business domain owns, publishes and supports its own data as a product, on shared self serve infrastructure, under one set of rules that every domain has agreed to follow. It is an operating model rather than a technology, so no vendor sells one. Three things change when a mesh is working: the domain owns its own tables, the domain carries the pager when they break, and every dataset is published with a stated schema, a stated freshness expectation and a named owner.
In simple terms, a data mesh moves the ownership of analytical data out of one central team and into the business teams that generate the data, then holds each of those teams to a published promise about what they produce. A shared platform gives every team the same tools for publishing, cataloging and checking their data, and one agreed set of rules is enforced automatically by that platform rather than reviewed by hand.
Datamesh written as one word and data mesh written as two words mean exactly the same thing. Both spellings appear in job adverts, conference talks and vendor documentation, and neither is more correct than the other. There is no technical distinction between them.
Data mesh was introduced by Zhamak Dehghani, then a principal technology consultant at Thoughtworks, in an essay titled "How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh", published on martinfowler.com on 20 May 2019. The four principles were named later, in a second essay called "Data Mesh Principles and Logical Architecture", published on 3 December 2020.
The four principles are domain oriented decentralized data ownership, data as a product, a self serve data platform, and federated computational governance. All four have to be present. A design that distributes ownership but has no federated governance produces disconnected silos, and a design that keeps ownership central is a decentralized warehouse rather than a mesh.
In practice a domain publishes six things rather than a table: the dataset itself with a stable name and location, a data contract stating the schema and the update frequency, documentation explaining each field in business language, quality checks with a visible pass or fail history, lineage showing where the data came from and what depends on it, and a named owner with an on call route to reach them. A quick test of whether a mesh is real is to pick any dataset a business report depends on and ask for those six things. If four or more are missing, what exists is shared tables with a mesh vocabulary layered over them.
A data warehouse centralizes both the data and the responsibility for it, which is what makes it good at producing one defensible number, while a data mesh keeps responsibility with the domains. A data lake is a storage decision rather than an ownership decision, so it is not really an alternative at all; a mesh is often built on lake or lakehouse storage. The failure mode of a lake, large volumes of data that nobody owns and nobody documents, is precisely what a mesh is designed to prevent.
Five layers are needed. Storage and compute, which is usually the warehouse or lakehouse you already run. A catalog, so a consumer in one domain can find and understand a product published by another. Lineage, so a break in one domain can be traced to the report it affects in another. Quality and observability, so the data contracts can be checked rather than merely claimed. And federated policy and access, so the agreed rules are applied automatically inside the platform. Most organizations already have the first layer and find their gap in the middle three.
Four tests decide it, and failing any one of them is a reason to stop. Can you name at least three business domains that each generate their own analytical data and have consumers outside themselves? Can each of those domains name one person accountable for its data products? Do the analytical queries come from more than one team? And can a domain publish a schema and freshness promise that the platform will check automatically? A governed warehouse remains the better answer where the requirement is one agreed version of a figure, and an event driven architecture fits better where the requirement is processing events as they arrive.
First step to AI Readiness
Table of Contents
Sneak peek from the data world.
Bring lineage, quality, governance, and AI together in one platform—so your teams and AI agents can act with confidence.
_For%20light%20backgrounds.svg)
.svg){kind=small}
.webp)