If you've been in any data conversation in the past few years, you've probably heard the phrase "data mesh." It's discussed with almost religious intensity in data engineering circles. But most explanations are either extremely abstract or buried in enterprise architecture diagrams.
Here's a plain-English breakdown of what data mesh is, why it emerged, and whether it's relevant to your organization.
The Problem Data Mesh Was Designed to Solve
In most organizations, data flows in one direction: source systems (your CRM, your e-commerce platform, your payment processor) send data to a central data warehouse or data lake, where a central data team transforms it and makes it available to everyone else.
Sohovi validates your dataset before it enters the warehouse — catching format errors, nulls, and duplicates at the source.
This works when the central team is small and the data footprint is manageable. It breaks down when the company grows. The data team becomes a bottleneck — every team that wants a new report or dataset has to wait for the central team to build and maintain it. Data quality degrades because the people maintaining the pipelines don't understand the business context of each domain. Ownership is unclear.
Data mesh is an architectural approach that distributes data ownership to the teams that generate and understand the data, rather than centralizing it in a single platform team. It's a decentralized model where the marketing team owns and maintains the marketing data domain, the sales team owns the sales data domain, and so on — with shared infrastructure and standards to keep everything interoperable.
The Four Core Principles of Data Mesh
Coined by Zhamak Dehghani in 2019, data mesh rests on four principles:
1. Domain ownership — Each business domain (marketing, finance, product, sales) owns and is accountable for the quality and availability of its data.
2. Data as a product — Each domain treats its data as a product to be delivered to internal consumers, with quality standards, documentation, and SLAs.
3. Self-serve infrastructure — A shared platform layer gives domain teams the tools they need to publish and consume data without building everything from scratch.
4. Federated computational governance — Global standards (data formats, quality thresholds, security policies) apply across all domains, but each domain enforces them locally.
Sohovi tracks quality trends across runs and alerts you when a metric — null rate, duplicate count, score — moves outside its normal range.
Why Data Quality Is Central to Data Mesh
One of the core arguments for data mesh is that data quality improves when the people closest to the data are responsible for its quality. A CRM team understands when a contact record is "good enough" better than a central data engineering team that has never spoken to a customer.
But distributed ownership only improves quality if each domain has clear quality standards and the tools to enforce them. Without that, data mesh can just as easily fragment quality further.
Is Data Mesh Relevant to Your Team?
Probably not — at least not yet. Data mesh was designed to solve problems that emerge at scale: dozens of data sources, multiple data teams, hundreds of consumers waiting on a central pipeline. If your business runs on a few CSV files and a Google Sheets dashboard, the concept is interesting but not actionable.
Sohovi gives you a full quality report on any spreadsheet in seconds — upload your file and see exactly what needs fixing.
Where data mesh thinking does apply to smaller teams is the principle of domain ownership. Even if you're a team of ten, assigning one person per dataset — who is responsible for quality, format standards, and documentation — dramatically improves reliability. That's the core idea of data mesh, minus the distributed platform engineering.
What This Means in Practice
If you're evaluating a move toward data mesh, start with the ownership question: who is responsible for each critical dataset, what does "good" mean for that dataset, and who gets paged when quality degrades?
A tool like Sohovi helps individual domain teams run quality checks on their data before publishing it downstream — ensuring the quality standards are actually enforced at the source, not just documented in a wiki.
The concept of data as a product is powerful at any size. Every team that publishes data to others should treat it with the care they'd give a deliverable to a customer — accurate, documented, and reliably maintained.
