What is data mesh, in plain terms?
Data mesh is an organisational approach to managing data at scale. Instead of one central data team owning every pipeline, table and report, each business domain owns its own data and publishes it as a product that the rest of the organisation can discover and use. It is an operating model, not a piece of software you buy. The idea was introduced by Zhamak Dehghani at Thoughtworks, and it is a response to a specific failure pattern: as an organisation grows, the central data team becomes a bottleneck that no amount of extra headcount seems to fix.
If you take one thing from this article, take this: data mesh is a way of distributing ownership and accountability for data across the people who understand it best, with shared governance holding the whole thing together. It is not a product category, and it is not the right answer for every organisation.
What problem does data mesh actually solve?
Picture a monolithic data platform run by a single central team. Every business unit that wants a dataset, a metric or a feed has to queue behind that team. The team does not deeply understand the finance domain, the supply chain domain or the clinical domain, so they spend enormous effort just working out what the data means before they can transform it. Requests pile up. Priorities collide. The backlog grows faster than the team can clear it.
This is not a failure of the people. It is a structural problem. A central team sitting between every data producer and every data consumer is a coordination bottleneck, and bottlenecks get worse as you scale, not better. The people who understand the data best, the domain teams who generate it, have been separated from the responsibility for serving it well.
Data mesh reframes the problem. Rather than asking a central team to understand every domain, it pushes ownership of data out to the domains themselves. The finance team owns and serves finance data. The logistics team owns and serves logistics data. Each becomes accountable for the quality, meaning and availability of what it publishes. This is closely related to the broader idea of treating data as a product rather than as exhaust from operational systems.
What are the four principles of data mesh?
Dehghani framed data mesh around four core principles. They work together, and adopting one or two of them in isolation is not really data mesh, it is just good practice with a fashionable label.
1. Domain-oriented decentralised ownership
Responsibility for data moves to the business domains that produce and best understand it. Each domain owns its own analytical data end to end, rather than handing raw tables to a central team and hoping the meaning survives the journey. Ownership includes the boring but essential parts: keeping the data accurate, documenting what fields mean, and being reachable when a consumer has a question.
2. Data as a product
Domains do not just dump data into a lake and walk away. They publish it as a product with a named owner, a clear interface, documentation, quality guarantees and a defined way to access it. The consumer should be able to find the product, understand it and trust it without booking a meeting with the team that built it. If you want a deeper treatment of what that means in practice, see what is a data product and the question of who owns a data product, because ownership is where most implementations succeed or fail.
3. Self-serve data platform
If every domain has to build its own storage, access control, lineage tracking and serving infrastructure from scratch, you have not decentralised, you have multiplied the work. So data mesh calls for a self-serve platform: shared, general-purpose infrastructure that lets a domain team publish a well-governed data product without needing deep platform engineering skills. The platform team stops being a bottleneck for content and instead provides the paved road that domain teams build on.
4. Federated computational governance
Decentralisation without shared rules produces chaos: incompatible identifiers, inconsistent definitions, no way to join data across domains, and no reliable answer to who accessed what. Federated computational governance is the counterweight. A cross-domain group agrees the global rules, interoperability standards, security policies, privacy requirements, and those rules are enforced automatically by the platform rather than by manual review. The word "computational" matters: governance that lives in a policy document nobody reads is not governance. This is the principle most organisations underestimate, and it is closely tied to data product governance as a discipline.
How is data mesh different from a data lake or warehouse?
A common confusion is treating data mesh as a new kind of storage technology that competes with a warehouse or lake. It is not. Data mesh is about who owns and serves data and how; a warehouse or lake is about where analytical data physically lives. You can implement a data mesh on top of warehouses, lakes, or a mix.
| Aspect | Centralised platform | Data mesh |
|---|---|---|
| Ownership | One central data team | Each business domain |
| What it is | An architecture and a team | An operating model |
| Bottleneck | Central team backlog | Distributed across domains |
| Governance | Central, often manual | Federated, automated |
| Scales by | Adding to the central team | Adding domains |
| Best fit | Smaller or single-domain orgs | Large, multi-domain orgs |
It is also worth separating data mesh from data fabric, a term it is frequently muddled with. They are not the same thing and they are not direct competitors; one is an organisational model and the other leans technical. That distinction has its own article: data mesh versus data fabric.
Who is data mesh for, and who is it not for?
Data mesh is an operating model designed for large organisations with genuinely distinct business domains, multiple autonomous teams, and a central data function that has become a chronic bottleneck. If that describes you, the model offers a coherent way to scale data work by scaling ownership rather than headcount.
It is not for everyone, and honesty here saves a great deal of pain. If you are a small team, or a single-domain business, or a startup where five people already know what every table means, adopting data mesh because it is fashionable will slow you down. You will pay the coordination and platform cost of decentralisation without having the scale problem that justifies it. The central bottleneck data mesh solves does not exist yet at your size, and you would be manufacturing overhead to solve it.
Data mesh is also not a silver bullet for a large organisation. It is an organisational change as much as a technical one. It asks domain teams to accept accountability they may not want, it requires real investment in a self-serve platform, and it depends on federated governance actually being enforced rather than merely agreed. Organisations that adopt the diagram without the operating discipline tend to end up with the same mess, just relabelled. Reorganising reporting lines does not fix data quality on its own.
A sober way to decide: do not start with the architecture. Start with whether your central data team is a bottleneck, whether your domains are distinct enough to own data meaningfully, and whether you are prepared to invest in the platform and governance that make decentralisation safe. If the answer to those is no, you probably do not need data mesh, and you may just need to treat a handful of your most important datasets as proper products.
Where does Integrius fit?
Let us be precise, because the market is full of tools claiming to be things they are not. Integrius is not a data mesh product. Data mesh is an operating model, and no vendor can sell you one in a box. You do not need to adopt data mesh to use Integrius, and you certainly do not need to draw a mesh diagram or reorganise your teams first.
What Integrius does is make the principle at the heart of data mesh, data as a product, actually enforceable. It is a self-hosted platform for building governed data products: a canonical schema per product, connectors across your source systems, field-level access control enforced at the point of serving, full dependency lineage, and a tamper-evident audit trail. In other words, it gives a domain team a concrete way to publish a data product with a real owner, real access rules and a real, auditable interface, whether or not the wider organisation ever calls the result a mesh.
The federated governance principle maps across too. Governance that lives only in a policy document is theatre; governance enforced by the platform when data is served is real. Because Integrius enforces access control and records lineage and access at the point of serving, the global rules a governance group agrees can be applied consistently across every product, which is the whole point of the "computational" in federated computational governance. For teams that need this to run inside their own network, on-premises or air-gapped, this is a question of self-hosted data governance as much as architecture.
So the honest positioning is this. If you are a large organisation genuinely adopting data mesh, Integrius can be the platform on which your domains build and serve governed products. If you are not, and most organisations are not, you can ignore the word "mesh" entirely and still get the benefit that made the idea popular in the first place: owned, governed, trustworthy data products that people across the organisation can actually rely on. The operating model is optional. The discipline of treating data as a governed product is what pays off.