How Knowledge Graphs Transform Master Data Management

Updated October 2026

Knowledge graphs transform master data management by treating relationships and hierarchies as first-class data rather than afterthoughts. A graph links each golden record to its sources, parents, partners, and products. That makes source mapping visible to business experts, gives matching more evidence, and hands AI agents connected context instead of isolated rows.

What is knowledge graph master data management?

Knowledge graph master data management stores master entities as connected nodes with typed relationships, and governs those links as carefully as the attributes. Customers, products, suppliers, locations, and employees all live in one model. The goal of MDM stays the same, which is one trusted version of each entity, but the graph also keeps the context around it.

Classic MDM grew up around golden records in relational hubs. Relationships existed, but they often sat in side tables that few people could read. For background on the discipline itself, see the guide to master data management definitions and types. This article covers what changes when the model becomes a graph.

Why is master data really a graph?

Master data is a graph because the entities it describes only make sense together. A customer belongs to a corporate family, buys products, ships to sites, and signs contracts. Neo4j argues that graphs model both hierarchical and non-hierarchical master data, and that the future of MDM lies in the value of relationships.

Even table-centric MDM vendors added graph views over time. Informatica's Hierarchy Manager shows a graph of how a record relates to other records, covering both employer and employee links and peer links. The question is no longer whether master data has relationships. It is whether those relationships are a core part of the model or a view bolted on top.

How do knowledge graphs change the MDM data model?

A knowledge graph makes three changes to the master data model. Relationships get their own types, rules, and history. One entity can sit in many hierarchies at once. And the model is described by an ontology that both people and machines can read.

Relationships become governed data

In a graph, "subsidiary of" or "supplied by" is a typed edge with properties such as start date, source, and confidence. Stewards can approve or reject a relationship the same way they approve an attribute. That matters for credit risk, sanctions screening, and supplier risk, where the link is often the fact that counts.

Hierarchies stop competing with each other

Table-centric MDM often forces one primary hierarchy per domain. A graph lets the legal entity tree, the sales territory tree, and the product category tree all point at the same customer node. For reference data such as category codes, the W3C SKOS standard defines broader and narrower relations for exactly this purpose.

The model explains itself

An ontology names each entity type, property, and relationship in business language. Business experts can read "Business Partner has Address" without decoding column names. For the wider case on why this shared model matters, see how ontology powers AI analytics.

How does mapping source systems to business concepts work?

Mapping works by linking every source table and column to a concept in the shared model, then generating the logical model and transformations from those links. Human effort moves from writing mapping spreadsheets to deciding what each field means. That is a question business experts can answer, which closes the usual gap between engineers and domain owners.

Example of two ways to store an address

System A stores an address as address_line_1, address_line_2, and address_line_3. System B stores street, zip_code, city, and country_code. In the graph, both sets of columns point at the Address concept. Fields that match one to one are obvious at a glance, and fields that need parsing carry an explicit transformation.

Once all sources are mapped, the graph can drive the rest of the pipeline. Each concept becomes a target entity with lineage back to its sources. Shape rules written in W3C SHACL can check that loaded data matches the model. The guide to ontology mapping covers the matching methods and tools in more depth.

How do graphs help with matching and entity resolution?

Graphs help matching by linking records through shared identifiers, so evidence accumulates across many weak signals. Two customer records may differ on name spelling but share a phone number and a billing address. In a graph, those shared nodes form a path that a matching rule or algorithm can score.

Neo4j describes two common graph algorithms for this work. Weakly Connected Components groups records that connect through shared identifiers, and works best when identifiers segment entities cleanly. Node Similarity scores pairs by their common connections, though Neo4j notes it is computationally intensive. Many teams use similarity to propose links and components to build the final clusters.

The graph also keeps every piece of match evidence, which helps stewards review and undo merges. For matching techniques, see what entity resolution is and how it works. For survivorship rules, stable IDs, and stewardship queues, see the guide to identity resolution and entity mastering.

Which MDM platforms use knowledge graphs in 2026?

Graph capabilities now show up in dedicated MDM products, in graph databases, and in platform ontology layers. The market also consolidated. SAP completed its purchase of Reltio on May 7, 2026 for 1,259 million dollars, according to its Q2 2026 statement. Salesforce completed its Informatica acquisition on November 18, 2025.

Reltio

Reltio builds its unified profiles on a graph database backbone and treats cross-domain relationships as part of the core model. SAP said Reltio will become a core capability in SAP Business Data Cloud, with MCP support for agents. Reltio stays available standalone for the foreseeable future, but non-SAP shops should watch how the roadmap evolves.

Informatica MDM

Informatica MDM has long supported hierarchies and relationship graphs through Hierarchy Manager. Its match and merge tooling is mature and widely deployed. Salesforce is folding Informatica into its Agentforce data foundation, so buyers outside Salesforce should check future packaging.

Stibo Systems STEP

Stibo Systems positions STEP as master data for AI agents and ships an MCP server that exposes modeled, governed data. It was named a Leader in the 2026 Gartner Magic Quadrant for MDM, according to that release. Its public material highlights business partner relationships but does not describe a graph engine.

Tamr

Tamr is an MDM platform that lists an Enterprise Knowledge Graph feature for connecting people and organization data. Pricing is based on golden records, with unlimited users. Tamr publishes no prices and offers a guided proof of concept rather than a free trial.

Neo4j and other graph databases

Teams that want full control build graph mastering on a general graph database. Neo4j offers matching algorithms, and AuraDB Professional starts at 0.09 dollars per GB per hour. The trade is that survivorship, stewardship, and write-back are yours to build. The graph database comparison covers other engines.

Microsoft Fabric IQ ontology

Fabric IQ's ontology item defines entity types, relationships, and rules, and binds them to live OneLake data. It can be generated from a Power BI semantic model or imported from RDF or OWL. It is still in preview, so treat it as a modeling layer to test, not a production MDM hub.

Should a knowledge graph replace your MDM hub?

In most enterprises, no. The hub and the graph do different jobs, and replacing a working hub rarely pays off. The common pattern keeps the hub as the owner of golden attributes and write-back, and adds a graph that holds relationships, hierarchies, and match evidence keyed by the same stable IDs.

A graph-native MDM product folds both jobs into one system, which suits teams starting fresh. A graph built on a general database suits teams with strong engineering and unusual relationship needs. Whichever pattern you choose, the stable entity ID is the contract that ties the hub, the graph, the warehouse, and your agents together.

Who should own the master data model?

Your company should own the master data model, because it encodes how the business defines its customers, products, and partners. That knowledge outlasts any vendor contract. Keeping the ontology, mappings, and entity IDs in open formats such as RDF, SKOS, or SHACL, on infrastructure you control, means a platform change does not erase that work.

Galaxy is an applied lab that builds semantic foundations like this with teams on the stack they already run, using internal tooling for ontologies, semantic models, and entity resolution. It builds in the open with Filament and plans to open source more of that tooling. The knowledge graph platforms comparison covers the wider platform field.

How do you start a graph-based MDM project?

Start small, with one domain where relationships already cause pain. Corporate customer hierarchies and supplier networks are common first choices. A narrow first domain proves the model, the IDs, and the stewardship flow before you add more.

1. Pick one domain and write down five questions the business cannot answer today.

2. Draft a small ontology for that domain with business owners in the room.

3. Map each source table and column to a concept, and record every transformation.

4. Match records, assign stable IDs, and load entities and relationships into the graph.

5. Validate the graph against shape rules and test the five questions.

6. Expose the entities to analysts and agents, then add the next domain.

Frequently asked questions

What is graph-based master data management?

Graph-based master data management stores customers, products, suppliers, and locations as connected entities rather than isolated rows. Relationships such as subsidiary of, supplied by, or located at are first-class data with their own rules and history. The graph still produces golden records, but it also keeps the context around each one, which hierarchies, compliance checks, and AI agents depend on.

Do knowledge graphs replace MDM hubs?

Usually not. Most enterprises keep an MDM hub for golden attributes, approval workflows, and write-back to operational systems. The knowledge graph sits beside it and holds relationships, hierarchies, and evidence around the same stable entity IDs. A graph-native MDM product such as Reltio combines both roles, but the two jobs remain distinct even when one product does them.

Why is master data naturally a graph?

Master data describes things that relate to each other. A customer belongs to a corporate family, buys products, ships to locations, and is served by employees. Neo4j argues that graphs model both hierarchical and non-hierarchical master data. Tables can store these links too, but every new relationship type means schema changes and more joins.

How do knowledge graphs handle MDM hierarchies?

A hierarchy is a set of parent and child edges in the graph, so one entity can sit in several hierarchies at once. A legal entity tree, a sales territory tree, and a product category tree can all point at the same customer. W3C SKOS adds broader and narrower relations for reference data such as category codes.

How does a knowledge graph help with matching records?

A graph links records through shared identifiers such as emails, phone numbers, or tax IDs. Neo4j describes using Weakly Connected Components to group linked records quickly and Node Similarity to score records that share many identifiers. The graph also keeps the evidence for every match, so stewards can see why two records merged.

What is source-to-concept mapping in MDM?

It is the step where every source table and column is linked to a business concept in a shared model, such as Address or Business Partner. Once mappings live in the graph, teams can generate the logical model, transformation specs, and lineage from them. Business experts review concepts instead of reading spreadsheets of field mappings.

Which MDM vendors use knowledge graphs in 2026?

Reltio, now owned by SAP, builds on a graph database backbone. Tamr lists an Enterprise Knowledge Graph feature in its MDM platform. Informatica MDM, now part of Salesforce, offers relationship and hierarchy views. Teams also build graph-based mastering on Neo4j or on ontology layers such as Microsoft Fabric IQ, which remains in preview.

How do AI agents use graph-based master data?

Agents need stable entity IDs and the relationships around them to answer questions correctly. A graph lets an agent resolve a name to an ID, then follow links to accounts, contracts, or shipments. Reltio and Stibo Systems both document MCP support so agents can query governed master data directly instead of guessing joins.

What standards matter for knowledge graph MDM?

For RDF-based graphs, SKOS models controlled vocabularies and hierarchies, OWL defines classes and relationships, and SHACL validates data against shape rules. For property graphs, ISO GQL was published in 2024 as a standard query language. Using open standards keeps the master data model portable if you change vendors later.

Where should a graph MDM project start?

Start with one domain where relationships cause real pain, such as corporate hierarchies for customers or supplier networks. Map a few source systems to shared concepts, load matched entities into a graph, and test the questions the business could not answer before. Expand to more domains only after IDs and stewardship work in the first one.