The data management community has spent the past three years debating whether data mesh renders master data management obsolete. The debate generates considerable heat but not always proportionate light. Both approaches address real problems, but they solve different problems — and the organizations that benefit most are typically those that understand which problems they actually have rather than adopting whichever framework is currently fashionable.

What MDM Actually Does

Master data management centralizes the definition, governance, and distribution of core business entities — customers, products, suppliers, locations, employees. The premise is straightforward: an organization should have one authoritative record for each entity, maintained according to consistent standards, and distributed to consuming systems through controlled channels.

In practice, MDM implementations involve creating a master data hub (or registry, depending on the architecture style), establishing data stewardship roles, defining matching and merging rules to resolve duplicate records, and building integration pipelines that synchronize the master data with operational systems.

This works well for entity types where consistency is genuinely critical. When your finance system, CRM, supply chain, and customer service platform all need to agree on who a customer is, having a single authoritative customer record eliminates the reconciliation nightmares that occur when each system maintains its own version of reality.

MDM has been around for decades, and its track record is mixed. Implementations frequently exceed budget and timeline. Organizational resistance to centralized governance is common — business units don’t want to surrender control over “their” data to a central authority. The technology isn’t the hard part; the organizational change management is.

What Data Mesh Proposes

Data mesh, originally articulated by Zhamak Dehghani at ThoughtWorks, takes the opposite organizational approach. Instead of centralizing data ownership, it distributes it to domain teams who understand their data best. Each domain treats its data as a product, with clear interfaces, quality guarantees, and documentation. A federated governance layer ensures interoperability without requiring centralized control.

The four principles — domain ownership, data as a product, self-serve data platform, and federated computational governance — directly challenge MDM’s centralized model. Data mesh argues that centralization creates bottlenecks, disconnects governance from domain expertise, and scales poorly in large, complex organizations.

Data mesh’s appeal is strongest in organizations where domain expertise is distributed, where centralized teams have become bottlenecks, and where different business units have legitimately different data needs that a one-size-fits-all approach can’t accommodate.

Where Each Approach Struggles

MDM struggles with:

• Scale. As the number of entity types and consuming systems grows, the central MDM team becomes a bottleneck. Every new integration, every schema change, every data quality issue flows through the same team.
• Domain complexity. Centralized teams rarely understand domain-specific data as well as domain experts. A centralized data steward managing product master data across ten product lines won’t understand the nuances of each line’s classification needs.
• Agility. MDM implementations tend toward rigidity. Changing the master data model typically requires formal change management processes that slow down business responsiveness.

Data mesh struggles with:

• Cross-domain consistency. When different domains own different aspects of the same entity, maintaining consistency becomes genuinely difficult. If the sales domain defines a customer differently than the support domain, reconciling those definitions is the exact problem MDM was designed to solve.
• Maturity requirements. Data mesh assumes domains have the capability and willingness to manage their data as products. Many organizations don’t have data engineering capability distributed across domains, making the “self-serve platform” principle aspirational rather than practical.
• Governance enforcement. Federated governance sounds elegant in theory. In practice, ensuring that dozens of domains all comply with interoperability standards without centralized enforcement requires organizational discipline that’s rare.

The Practical Synthesis

The most effective implementations I’ve observed don’t choose one approach exclusively. They apply MDM principles to entity types where cross-organizational consistency is non-negotiable (customers, financials, regulatory data) and data mesh principles to domain-specific analytical data where local ownership produces better outcomes.

This isn’t a novel insight — it’s essentially pragmatism over ideology. But it’s surprising how often organizations pursue one approach dogmatically, either because a vendor sold them an MDM platform or because a consultant presented data mesh as the inevitable future.

Several practical patterns work well in this hybrid model:

Shared entity services with domain extensions. A central service maintains core customer attributes (identity, contact information, account status). Domain teams extend the customer record with domain-specific attributes that they own and govern. The central service provides the “golden record” for identity; domains provide the context.

Federated governance with centralized standards. Interoperability standards (naming conventions, data formats, API specifications) are defined centrally. Governance of data quality within those standards is delegated to domains. This gives domains autonomy while maintaining the ability to combine data across domains.

Platform-enabled self-service. Central teams build data infrastructure (catalogues, quality monitoring, lineage tracking) as a platform. Domains use the platform to manage their data products. This addresses the capability gap that undermines pure data mesh implementations.

Technology Considerations

The tooling landscape has evolved to support hybrid approaches. Modern data catalogues like Alation and Collibra support both centralized governance workflows and distributed data product management. Data quality platforms increasingly offer domain-level ownership models with organization-level visibility.

AI-powered data management tools are accelerating this convergence. Automated matching, classification, and quality monitoring reduce the operational burden that historically made MDM expensive to maintain. Organizations exploring how AI can support their data governance operations have found that firms like Team400 offer practical guidance on integrating AI capabilities into existing data management architectures without requiring wholesale platform replacement.

Making the Decision

Rather than asking “should we do MDM or data mesh?”, organizations should ask specific diagnostic questions:

• Which entity types require cross-organizational consistency? (These are MDM candidates.)
• Which data assets are primarily consumed within a single domain? (These are data mesh candidates.)
• Does the organization have distributed data engineering capability? (If not, data mesh is premature.)
• Is the central data team a bottleneck? (If so, some decentralization is needed regardless of what you call it.)

The answers will vary by organization and probably by entity type within the same organization. That’s fine. The goal isn’t architectural purity — it’s effective data management that serves business needs. Pragmatic hybrid approaches, while less elegant than pure models, tend to deliver better outcomes than ideological commitment to either extreme.