Master Data Management Using a Graph Database

What Master Data Management Means

Master data management is the discipline and tooling used to keep one trusted, consistent record for the core entities a business depends on: customers, products, suppliers, employees, locations. The same customer or product typically exists in several source systems (CRM, billing, support, logistics) under different identifiers, spellings, or formats. An MDM program detects when records from different systems refer to the same real-world entity, resolves them into a single authoritative version, often called a golden record, and governs how that record is created, updated, and distributed back to consuming systems.

Why Relationships Are the Hard Part

Storing the records themselves is not the hard problem. The hard problem is tracking how records relate: which records are duplicates of each other, which customer belongs to which household, which product is a component of which bundle, which supplier is a subsidiary of which parent company. A relational schema can model this with foreign keys and join tables, but multi-hop questions, such as following a chain of duplicate-match links or walking an ownership hierarchy several levels deep, require recursive queries or repeated joins. As the number of relationship types grows, those queries get slower and harder to maintain.

A graph database stores relationships as first-class data. Each connection between entities already exists as an edge with a type, a direction, and its own properties, so traversing from one entity to its neighbors means following those edges directly rather than scanning or rejoining tables. In engines built around this index-free adjacency, the cost of a traversal depends mainly on how many edges are visited, not on the total size of the dataset; the exact performance characteristics vary by implementation, including whether the graph layer runs on native storage or on top of a relational engine.

How a Graph Model Represents Master Data

In a labeled property graph, each master entity, a customer, a product, a location, becomes a node with a label and a set of properties holding its attributes. Relationships become edges with their own type and properties, for example SAME_AS, PARENT_OF, or LOCATED_AT, which capture both business hierarchy and the output of identity resolution.

The identity resolution process typically works like this:

• A matching step compares candidate records (by name, address, tax ID, or other attributes) and scores how likely they are to represent the same entity.
• When the score passes a threshold, the system creates a SAME_AS edge between the two records, often storing the match confidence as an edge property.
• A clustering step then traverses the network of SAME_AS edges, commonly using a connected-components algorithm, to group all records that are transitively connected into a single cluster, even when no single pair of records was compared directly.
• One record in each cluster is selected or computed as the golden record, and the cluster is tagged so downstream systems can look it up.

The same structure, nodes connected by typed edges, is reused to represent product hierarchies, organizational charts, and household groupings without adding new tables or join logic.

A Small Example

The example below uses openCypher, the graph query language originally developed for Neo4j and now implemented, as a subset, by other engines including Apache AGE on PostgreSQL. It creates two duplicate customer records, links them with a SAME_AS edge carrying a match confidence, then queries for all pairs still awaiting manual review.

// Create two source records for the same real-world customer
MERGE (c1:Customer {source_id: 'CRM-100'})
SET c1.name = 'Acme Corp', c1.city = 'Austin'

MERGE (c2:Customer {source_id: 'BILL-204'})
SET c2.name = 'Acme Corporation', c2.city = 'Austin'

// Record the match found by the resolution step
MERGE (c1)-[r:SAME_AS]->(c2)
SET r.confidence = 0.92, r.reviewed = false

// Find linked pairs that still need manual confirmation
MATCH (a:Customer)-[r:SAME_AS]->(b:Customer)
WHERE r.reviewed = false
RETURN a.name, b.name, r.confidence
ORDER BY r.confidence DESC

In a production system, the match step that creates the SAME_AS edge is usually driven by a separate scoring process (rules-based or probabilistic), not written by hand. The graph only needs to store the result: which records are linked, and with what confidence.

Trade-offs Versus Relational MDM Hubs

• Relationship-heavy queries: a graph database is faster and simpler to query when the workload is dominated by traversals, such as "find every record linked to this one, directly or transitively" or "walk up the ownership chain." A relational hub can answer the same questions but needs recursive CTEs or application-level loops that get harder to maintain as new relationship types appear.
• Flat lookups and reporting: if most access is simple key lookups, aggregate reports, or joins across a small, stable schema, a relational database remains simpler to operate, backup, and audit, and integrates more easily with existing BI tools.
• Schema flexibility: adding a new relationship type in a graph model usually means adding a new edge type, with no migration. Adding an equivalent relationship in a relational schema often means a new join table and schema change.
• Tooling and staff familiarity: relational databases have a much larger pool of experienced administrators and mature backup, replication, and monitoring tooling. Graph databases, including Apache AGE on top of PostgreSQL, narrow that gap but still require the team to learn graph query patterns.
• Hybrid approach: many MDM implementations keep source-of-truth records in a relational system and use a graph layer specifically for identity resolution and relationship navigation, syncing golden records back once resolved. This avoids rewriting existing integrations while gaining the benefits of graph traversal where it matters most.

Common Mistakes

• Treating match confidence as binary. Storing only a yes/no SAME_AS edge discards information needed later for audits or re-tuning the match algorithm. Store the confidence score and the matching rule or model version on the edge.
• Skipping transitive closure. If record A matches B, and B matches C, but A and C were never directly compared, failing to cluster transitively creates split golden records. The clustering step must traverse the full connected component, not just direct matches.
• No source lineage. A golden record that does not retain which source systems and source IDs contributed to it is hard to debug when a downstream system reports a wrong value. Keep the original source records and link them to the golden record rather than overwriting them.
• Letting the graph become the only copy. Without a defined system of record and a backup and recovery plan equal to what the relational systems already have, the graph becomes a single point of failure for data that the business depends on.
• Ignoring governance. A graph makes it technically easy to merge records; it does not decide which merges are correct. Human review workflows and audit trails for merges and un-merges are still necessary, especially for regulated data like customer or financial records.