Blog Post · 12 min read · January 2026
Data Mesh in Practice
By Thinklytics Research, Data Architecture Practice
Data mesh is the most discussed and least successfully implemented architecture of the past three years. This paper separates the organizational reality from the conference talk, based on implementations across healthcare, financial services, and manufacturing.
Topics covered
- Data mesh architecture
- Domain ownership
- Federated governance
- Implementation sequencing
Frequently asked questions
What is data mesh and how is it different from a data warehouse?
Data mesh is an organizational pattern where domain teams own their analytical data products instead of a central data platform team owning everything. The warehouse still exists as infrastructure. The change is who is accountable for the quality of each domain's data.
When is a company ready for data mesh?
When there are 4 or more product or business domains with their own engineering capacity, when the central data team is the bottleneck on every domain's needs, and when there is leadership sponsorship for shifting accountability from central to domain. Without all three, mesh creates more silos, not fewer.
What is the most common failure mode for data mesh implementations?
Domain teams take ownership of their data products without the platform team building the federated governance plane. The result is 8 domain-specific definitions of revenue. Mesh requires the platform team to invest more, not less.
How long does a data mesh transition typically take?
Plan for 18 to 30 months from kick-off to a steady-state where 60 percent or more of analytical workloads flow through domain-owned data products. The first 6 months are platform plumbing. The next 12 are domain onboarding. The last 6 are pruning what the warehouse no longer needs to own.
Should a 200-person company adopt data mesh?
Almost never. Below ~1,000 employees the central data team is faster than coordinating across domains. Mesh adds value at the scale where coordination overhead exceeds central-team throughput. For most mid-market companies the better play is a strong central team with clear domain liaisons.
What is the relationship between data mesh and data governance?
Mesh raises the governance bar, it does not lower it. The federated governance layer has to enforce metric standards across domains so each domain's data product is interoperable. Without that layer, mesh becomes a polite name for siloed data.
Can we run a mesh and a central warehouse at the same time?
Yes, and most successful implementations do. Domain teams own the analytical data products their domain produces; the central warehouse owns the cross-domain rollup metrics and the federated governance plane. Both layers need to exist, with clear contracts between them.
What's the most underrated investment in a mesh transition?
The metric layer. Every domain will rederive metrics if there is no shared metric service. Standing up dbt, LookML, Tableau Pulse, or a Power BI shared semantic model is the prerequisite that makes the mesh actually federated.