Data mesh is not a technology you install. It is a way of deciding who owns data, supported by a platform that makes ownership practical. The diagram below shows all four principles in one picture, because a mesh with three of them is just a reorganisation.
The four principles, and what each one changes
- 1Domain ownership moves the work to the people who understand it. The team that runs sales owns the sales data, including its quality and its definitions. A central team no longer sits between the question and the answer, which is what removes the queue that motivated the mesh in the first place.
- 2Data as a product sets the bar for what a domain publishes. A published table has an owner, a stable name, a promise about freshness and a description someone outside the team can read. Without this, decentralised ownership just produces more tables nobody trusts.
- 3A self-serve platform stops every domain rebuilding plumbing. Ingestion, storage, modelling and serving are provided once. Domains spend their time on meaning rather than on connectors and orchestration, which is the only way a small domain team can realistically own a data product.
- 4Federated governance keeps the whole thing joinable. Standards are agreed together and enforced by the platform: one customer ID, published freshness, access by role, everything discoverable. This is what stops a mesh becoming a set of silos with better branding.
Where the word mesh comes from
The mesh is not the domains. It is the connections between them. A domain consumes another domain’s published data product directly, governed by a data contract that states the schema, the freshness and the terms of use – not by raising a ticket with a central team. Draw three domains side by side with no arrows between them and you have drawn an organisation chart; the arrows are the architecture.
Why all four have to be present
The common failure is adopting domain ownership without the platform. Each domain is handed responsibility and no tooling, so they build their own pipelines, and within a year you have the original problem multiplied by the number of domains. The reverse fails too: a platform without ownership is just a warehouse with more steps.
Is a data mesh right for you?
- It helps when the bottleneck is one central team serving everyone, and domains have people who can own a data product.
- It hurts when nobody in a domain can be accountable for data, because ownership with no owner is the same as no ownership.
- It is orthogonal to your storage choice. A mesh can run on a warehouse, a lakehouse or both.
How it compares to a data fabric
A fabric answers the same discoverability problem with technology and metadata rather than with ownership. The two are not alternatives, and most teams end up combining them – the differences are drawn out side by side on our data fabric vs data mesh diagram.
What this looks like in Peliqan
Peliqan can act as the self-serve layer under a mesh: managed ELT from 300+ sources, SQL and Python models, and access control per user, so a domain team publishes a product without operating infrastructure. The shared definitions live in a semantic layer, which is what keeps domain-owned tables joinable.
Use this diagram wherever you like
The diagram is free to use, including commercially, as long as there is a visible link back to this page. Download the PNG for slides and documents, or the SVG if you want to edit the labels. No email required. You can browse the rest of the set in the Peliqan diagram library.
Ready to build this on your own data? Get started with Peliqan.
