Master Data Management versus Reference Data Management: which do you need?
Two product categories get confused regularly. MDM (Master Data Management) and RDM (Reference Data Management, also called a reference data registry). Vendor marketing blurs them. Buying the wrong one is expensive.
They solve different problems. Pick the one that matches your actual problem.
Side by side
| MDM | RDM | |
|---|---|---|
| Manages | Complex business entities | Controlled lists |
| Examples | Customers, suppliers, products | Country codes, status values |
| Key feature | Matching, survivorship, hierarchies | Authoritative lists |
| Typical record count | Tens of thousands to millions | Tens to thousands |
| Typical attributes per record | Twenty plus | Two to five |
| Cost | Hundreds of thousands a year | Tens to hundreds |
| Implementation | Six to eighteen months | Weeks to a few months |
| Question it answers | "Are these two records the same entity?" | "What are the legal values for this field?" |
Which problem do you have?
Pick MDM if the painful questions sound like:
- "Is this the same customer as that one, or are they different?"
- "Which of these supplier records is the right one?"
- "Why are John Smith and Jon Smith showing up as one customer?"
These are identity and matching problems. The solution involves fuzzy matching, survivorship rules, hierarchy management, stewardship workflows.
Pick RDM if the painful questions sound like:
- "What are the legal values for status?"
- "Why does Finance use different country codes than Sales?"
- "Which cost centres are currently active?"
These are list management problems. The solution involves authoritative lists, ownership, change history, downstream propagation.
The common mistake
Companies buy MDM because that is the category they have heard of. They have only an RDM problem. They pay hundreds of thousands of euros for capability they will never exercise, and the implementation drags on for a year before delivering value. By our rough count, about two-thirds of MDM evaluations should be RDM evaluations.
A typical example: a finance team complains that customer codes do not match between the ERP and the CRM. The IT team proposes MDM. Eighteen months and a million euros later, the codes still do not match. The actual problem was that two different lists of "active customers" existed in two different systems, neither of which was the source of truth. An RDM project would have solved this in three months for a tenth of the cost.
The order of operations
Most teams should:
- Build the RDM first. Cheaper, faster, more common problem.
- Watch what is left. If the remaining pain is about identity and matching, that is the signal for MDM.
- Only then evaluate MDM seriously.
Going the other way, starting with MDM and discovering you still need a reference data layer underneath, is a more expensive lesson.
FAQ
Are MDM and RDM the same product from some vendors? Some vendors bundle them. The bundle is fine if you genuinely need both. Most teams pay for the bundle and use only the RDM half.
Can we build an RDM ourselves? Yes, for small lists. The build cost is real once you cross into multi-user editing, audit, and APIs. Off-the-shelf RDM products are cheap enough that the build-versus-buy math usually favours buying.
Where does row-level security fit? RLS is a feature, not a category. It can live in either MDM or RDM. It matters most for RDM-style data products where different consumers see different slices of one list.
What about the data warehouse? The warehouse is the analytical store; neither MDM nor RDM replaces it. The lists managed in RDM and the entities reconciled in MDM still need somewhere to live. The warehouse is downstream of both.