/

Comparison

Semantic Data Unification vs MDM: What Enterprise Data Teams Should Actually Choose in 2026

Intergalactic Data Labs

—

—

12 min read

Table of contents

Summarize

Updated October 2026

Choose MDM when you need approved golden records for a few domains, with stewards and write-back to operational systems. Choose semantic data unification when the problem is connecting entities, relationships, and definitions across many domains for analytics and AI. Most large enterprises end up running both, with MDM issuing stable IDs that the unified model links into wider context.

Question

MDM

Semantic data unification

Core output

Golden record per entity

Linked model of entities and meaning

Scope

One to a few domains

Many domains at once

Matching result

Merge and survivorship

Links plus match evidence

Relationships

Mostly hierarchies

First-class and typed

Main consumers

ERP, CRM, billing

Analytics, search, AI agents

Governance style

Steward approval workflows

Shared definitions and lineage

Write-back

Common

Rare

This guide focuses on the choice itself. For definitions, see the master data management glossary and the semantic data unification guide.

What problem does each approach solve?

MDM solves inconsistent records for a bounded set of domains. IBM describes it as a way to consolidate core data such as customer, product, and location records into a golden record, backed by a data model and stewardship. The output is a trusted row that operational systems can rely on.

Semantic data unification solves inconsistent meaning across domains. It resolves entities, maps them to a shared model of concepts and relationships, and keeps lineage back to every source. The output is a connected model that answers questions no single domain can answer alone.

The two overlap in entity resolution. Both need to know that three customer records describe one company. They differ in what happens next. MDM collapses the records into one approved version. Unification keeps the links and connects the entity to everything around it.

What changed in 2026 that affects the choice?

The biggest change is that the categories are converging. MDM vendors now ship graphs and agent access, and data platforms now ship ontologies. That makes the label on a product less useful than the job it actually does.

MDM vendors moved toward graphs and agents

Reltio documents each entity as a node in the Reltio graph, with related entities included in the profile. SAP closed its Reltio purchase on May 7, 2026 for 1,259 million dollars. Salesforce completed its Informatica acquisition in November 2025.

Stibo Systems launched an MCP server on June 29, 2026 that exposes relationships and hierarchies to agents. Tamr lists an Enterprise Knowledge Graph and MCP connectivity on its pricing page. Graph thinking is now part of mainstream MDM.

Data platforms moved toward ontologies

Microsoft Fabric IQ now has an ontology item in preview that defines entity types and relationships and binds them to live source data. Palantir describes its Foundry Ontology as an operational layer for the organization made of objects, links, and actions. These products do unification work without calling themselves MDM.

AI raised the cost of missing meaning

The evidence that context helps AI keeps growing. In one benchmark, GPT-4 scored 16 percent on raw SQL and 54 percent over a knowledge graph. An April 2026 study found that a short document of business semantics added 17 to 23 points of accuracy across three frontier models. Gartner predicts that through 2026, organizations will abandon 60 percent of AI projects that lack AI-ready data.

Which should you choose for common scenarios?

Most real programs map to a handful of scenarios. Use the matrix below as a starting point, then test it against your own constraints.

Scenario

Lead with

Why

Duplicate customers across three CRMs

MDM

Bounded domain, needs one approved record

Supplier onboarding with approvals

MDM

Steward workflow and write-back to ERP

Customer 360 across contracts and tickets

Both

MDM IDs plus cross-domain links

AI agent answering account questions

Unification

Needs relationships and definitions

Post-merger integration of two companies

Both

Match entities, then align meaning

Metric drift across BI tools

Unification

Shared definitions, not record cleanup

Product data for ecommerce channels

MDM

Product hub with channel publishing

Risk or fraud network analysis

Unification

Relationships carry the signal

When MDM should lead

MDM should lead when someone must approve a record before it reaches an operational system. Supplier onboarding, product launches, and regulated customer data are typical cases. It also fits when the problem is narrow and well defined, such as duplicate customers in a few CRMs.

Reltio lists four main MDM styles, from registry to centralized. Registry leaves sources unchanged and is the cheapest, while centralized gives the most control at the highest cost. Picking the lightest style that meets your approval needs keeps the program small.

When semantic data unification should lead

Unification should lead when the question crosses domains. Examples include which customers are exposed to a delayed shipment, or why two dashboards disagree on revenue. No single golden record answers those questions, because the answer lives in the relationships and definitions between domains.

It also fits when schemas change often. The W3C notes that RDF supports schema evolution without changing every data consumer. A graph or ontology model can add a new entity type or relationship without reworking a fixed master schema.

When you need both

You need both when operations want approved records and analysts or agents want connected context. This describes most large enterprises. The usual answer is to let MDM master a few core domains and let the unified model link those mastered IDs to everything else.

How do the two work together in a hybrid architecture?

In a hybrid, MDM issues stable IDs and approved attributes, and the unified model links those IDs to the rest of the business. Each system keeps one job. The shared entity ID is the contract between them.

Layer

Owned by

Job

Matching and golden records

MDM hub

Approve and publish core entities

Entity resolution for other data

Warehouse or ER engine

Link records outside MDM scope

Ontology or semantic model

Data platform team

Define concepts, relationships, metrics

Graph or virtual layer

Data platform team

Serve relationship queries

Agent and BI access

Consumers

Query through governed interfaces

Not every relationship query needs a copy of the data. Stardog virtual graphs, for example, let teams query sources in place by rewriting SPARQL into native SQL. Fabric IQ bindings also leave source data in the system that owns it.

For the full layer-by-layer design, see the semantic data unification architecture blueprint. For how hubs and graphs split master data, see how knowledge graphs transform MDM.

How should entity resolution fit into the decision?

Entity resolution is the shared foundation, so decide where it lives before choosing anything else. If MDM owns matching for core domains, the unified model should reuse those IDs instead of matching again. Records outside MDM scope still need a matcher, and that matcher should produce IDs in the same format.

Options range from MDM engines to standalone tools. Splink is an MIT-licensed Python library that claims to link a million records on a laptop in about a minute, though you tune and run it yourself. Senzing sells an entity resolution engine priced by records, at 58,560 dollars a year for 10 million records.

The key design choice is whether to keep match evidence. Reltio assigns each entity a unique URI before merging, so merges can be reversed. Keeping evidence lets people and agents see why records were joined. For a deeper look, read about identity resolution and entity mastering.

How do you score your own situation?

Score each statement from 0 to 2, where 0 means not true and 2 means very true. Add the MDM scores and the unification scores separately. A clear gap points to one lead approach, and two high totals point to a hybrid.

Statement

Points toward

Records need human approval before use

MDM

Clean data must flow back into ERP or CRM

MDM

The problem sits inside one or two domains

MDM

Auditors ask who changed a master record

MDM

Questions cross three or more domains

Unification

Teams disagree on what metrics mean

Unification

AI agents need context, not just rows

Unification

Schemas and sources change every quarter

Unification

Run the exercise with both the governance lead and the analytics or AI lead in the room. The two groups often score the same company very differently. That gap is useful, because it shows which parts of the business need which approach.

What should you ask vendors in either category?

Ask about jobs, not labels. A vendor may sell MDM with a graph inside, or an ontology tool with matching built in. The questions below expose what each product actually does.

  • How are match decisions stored, and can a merge be reversed?

  • Which relationships can be modeled beyond parent and child hierarchies?

  • How do approved records get written back to operational systems?

  • How do agents reach the data, and is access read only or read and write?

  • Can you export the model, rules, and IDs in an open format?

  • Can the product consume IDs from an MDM hub you already run?

Watch for vendors who promise a single source of truth without saying whether that means a golden record or a connected model. Rule-only matching with no probabilistic option is a risk in messy data. A vendor with no story for coexisting with your current hub is likely oversimplifying.

Who should own the model and the IDs?

You should. Entity definitions, relationship types, match rules, and metric logic capture how your business works. That is institutional knowledge, and it should live in open formats on infrastructure you control rather than inside one vendor's proprietary schema.

Standards help with portability. RDF and SHACL describe graph data and its rules, and the Open Semantic Interchange effort entered the Apache Incubator as Apache Ossie in July 2026. Ask every vendor for a written export path before signing.

Some teams build this with a partner. Galaxy is one example. It sets up semantic layers, ontologies, and entity resolution on the stack a team already runs with internal tooling, builds in the open with Filament, and plans to open source more. For how semantic layers, graphs, and retrieval compare for AI, see RAG vs knowledge graph vs semantic layer.

Frequently asked questions

What is the difference between MDM and semantic data unification?

MDM produces governed golden records for a few domains such as customer, product, and supplier, and often pushes them back to operational systems. Semantic data unification links entities, relationships, and business meaning across many domains into one shared model. MDM answers which record is the trusted one. Unification answers how all the records and concepts connect.

Is MDM enough for customer 360?

MDM is enough when customer 360 means one deduplicated customer record shared by CRM, ERP, and billing. It falls short when the program must also connect customers to contracts, tickets, devices, and partners across many systems. That wider view needs cross-domain relationships and shared definitions, which is the job of semantic data unification, usually on top of the MDM IDs.

Can semantic data unification replace MDM?

Rarely, and only when nobody needs approval workflows or write-back to operational systems. Unification links and explains data but usually does not route exceptions to stewards or publish approved records into an ERP. If your auditors or operations teams depend on approved golden records, keep MDM for that job and let the unified model consume its IDs.

Do I need MDM before semantic data unification?

No. Many teams start with entity resolution and a shared model in the warehouse and add MDM later for the domains that need stewardship. What you do need is stable entity IDs. Whether a hub, an open-source matcher such as Splink, or a commercial engine produces them, every downstream model and agent should reference the same IDs.

How does entity resolution differ between MDM and unification?

Both use the same matching techniques, deterministic rules and probabilistic scoring. MDM feeds matches into merge and survivorship rules that pick one value per attribute. Unification keeps the links, match evidence, and source records so people and agents can see why records were joined. Reltio, for example, keeps merges reversible by assigning each entity a unique URI.

Which is better for AI agents?

Agents need both trusted IDs and the meaning around them. MDM gives clean customer and product records. Unification gives the relationships, definitions, and metrics an agent needs to answer cross-domain questions. A 2026 study found that adding explicit business semantics raised text-to-SQL accuracy by 17 to 23 points across three frontier models.

Are MDM vendors adding knowledge graphs?

Yes. Reltio documents each entity as a node in the Reltio graph, and Tamr lists an Enterprise Knowledge Graph feature. Stibo Systems launched an MCP server in June 2026 that exposes relationships and hierarchies to agents. The category lines are blurring, so judge vendors by the jobs they do rather than the label they use.

What does a hybrid MDM and semantic architecture look like?

MDM masters a few core domains and issues stable IDs. Those IDs flow into the warehouse, where an ontology or semantic model links them to contracts, events, tickets, and metrics. A graph or virtual layer serves relationship queries, and agents reach both through governed interfaces. Each system keeps one job, and the shared ID ties them together.

How long does each approach take to show value?

Neither has a reliable industry benchmark, so treat vendor timelines with care. A registry style MDM hub that leaves sources unchanged is the fastest MDM path, according to Reltio. A unification pilot that models one cross-domain question over existing warehouse tables can show results quickly. Scope, not category, drives the timeline in both cases.

What should I own in either approach?

Own the model and the IDs. Entity definitions, relationship types, match rules, and metric logic are institutional knowledge, so keep them in open formats you can export. Ask every vendor for a written export path. Standards such as RDF, SHACL, and the Apache Ossie interchange effort make the model easier to move later.

More articles

Stay up to date with what we’re building

Stay up to date with what we’re building

Stay up to date with what we’re building

Questions

Answered

FAQ

What does Galaxy do?

What is Filament?

What is enterprise context management?

What does working with Galaxy look like?

How do you handle security and compliance?

Why does Galaxy build in the open?

Own your knowledge stack

Own your knowledge stack

Copyright © 2026 Galaxy. All rights reserved.