Data mesh is not a tool or a platform purchase — it is a decentralized approach to data architecture that moves ownership from a single central team to the business domains that actually create and use the data. The concept, originated by Zhamak Dehghani, rests on four principles that its author describes as "collectively necessary and sufficient" to enable scale while avoiding siloed, incompatible data. For an enterprise weighing the move, the practical question is not what data mesh means in the abstract, but precisely which responsibilities, team structures, and governance mechanisms must change.
Introduction to Data Mesh Architecture
A data mesh organizes data by business domain — marketing, sales, finance, customer service — rather than funneling everything through one central pipeline. As Databricks explains, data is owned and managed independently by multiple business domains instead of one team managing data for the whole organization, though central rules for governance keep data interoperable, safe, and semantically consistent.
The model emerged as a response to the strain that scale places on centralized teams. Google Cloud notes that data mesh is "a shift in how companies think about their data," not merely a new set of tools, and that its four principles are what make it effective at solving the problems of traditional centralized architectures. AWS describes those problems concretely: a central data team must manage conflicting priorities with limited domain knowledge, while business units disconnected from data consumers lack the incentive to provide meaningful, correct, and useful data.
The result, according to Databricks, is an overwhelmed central team that hinders business users from accessing the data they need. Data mesh addresses this by placing data management in the hands of domain experts who understand the data they are working with.
