MDM or Just Entity Resolution? 5 Questions to Answer Before You Choose in 2026
TL;DR: Master data management governs a single trusted record. Entity resolution decides which incoming records describe the same real-world entity. Most teams need both, not one instead of the other. These five questions decide whether to extend an existing MDM platform or replace it with a leaner resolution layer in 2026.
Work out which shape the problem actually has. Talk the five questions through with our team, or test a real-time resolution layer against your own data. Book a Demo or Try Tilores Studio (Free).
On this page
- What actually separates an MDM platform from an entity resolution engine?
- Question 1: Do you need governance and stewardship, or just a resolved record?
- Question 2: Can your golden record be hours old, or does it need to be current at query time?
- Question 3: Are you extending an MDM platform you already run, or replacing one?
- Question 4: How many entity domains do you actually need to resolve?
- Question 5: Where does your data have to live?
- The five questions as a decision table
What actually separates an MDM platform from an entity resolution engine?
Master data management, as a category, is a governance discipline. Informatica’s own definition puts it plainly: MDM “involves creating a single master record for each person, place, or thing in a business, from across internal and external data sources and applications.” The record that discipline produces is usually called a golden record, described as “the essential information upon which a business or organization relies,” and the whole exercise “relies heavily on the principles of data governance.”
Entity resolution is narrower and sits inside that process rather than beside it. It answers one question: do these two records describe the same real-world person, company, or thing? AWS frames its own entity resolution service the same way, as something that “helps you match, link, and enhance related records stored across multiple applications, channels, and data stores,” offering “rule-based matching, machine learning-based matching, and data service provider-led matching” as the available techniques.
Put the two together and the relationship is clear: matching is the decision, governance is what happens once that decision is made. An MDM platform without a matching engine cannot function. A matching engine without governance can still be genuinely useful, if the problem you have does not need stewardship workflows on top of it.
We built Tilores as the second piece: a real-time entity resolution layer that can sit underneath an existing MDM platform to keep its golden records current, or stand on its own where a full governance layer is not the problem you are actually solving. Five questions decide which shape fits.
Question 1: Do you need governance and stewardship, or just a resolved record?
Full MDM earns its complexity when a business needs stewardship: a named owner for data quality rules, an approval workflow before two records merge, a change history a data steward can open and explain, and survivorship logic that decides which source wins when two records disagree on a customer’s address. That is organisational process as much as software, and it is the reason MDM implementations involve business stakeholders, not just an engineering team.
A resolved record, on the other hand, is what an operational system actually consumes: one entity ID, one current view, fed into a CRM, a fraud model, or an AI agent’s context window. If nobody in your organisation is going to review merge decisions by hand, and the record only needs to be correct rather than governed, a dedicated resolution layer answers the whole requirement on its own.
Most regulated teams end up needing both, at different points in the same pipeline: governance for the record a compliance officer signs off on, and a resolution layer feeding the systems that cannot wait for that sign-off cycle.
The combined pattern across five questions points to full MDM, a focused resolution layer, or the two working together.
Question 2: Can your golden record be hours old, or does it need to be current at query time?
Nearly every MDM platform builds its golden record on a scheduled batch job that runs every few hours, or overnight. That is a deliberate, reasonable design choice for a governed record: stewardship review does not happen in real time either, so matching on the same cadence is consistent.
The cost shows up the moment an operational system needs the answer sooner than the next batch window. A customer changes address, a company changes ownership, or a new account opens, and every downstream system stays unaware until the scheduled job catches up. For a fraud check, an underwriting decision, or an AI agent answering a live question, that lag is the whole problem.
Tilores resolves records as they arrive rather than on a schedule: a new record becomes visible in the resolved entity in under 150 milliseconds on the managed AWS path, and in around 1 millisecond self-hosted next to the workload. If your use case can tolerate an overnight golden record, batch MDM matching is not a weakness to route around. If it cannot, that gap is the entire case for a dedicated real-time layer, whether you keep your MDM platform or not.
| Batch matching inside MDM | Real-time resolution layer | |
|---|---|---|
| New record visible | Next scheduled run | Under 150ms (1ms self-hosted) |
| Relationship changes | Missed until next job | Detected immediately |
| Regulatory reporting | Point-in-time snapshot | Current state on demand |
| Matching quality on messy data | Depends on configured rules | Normalises names, addresses, and phone formats before matching |
Question 3: Are you extending an MDM platform you already run, or replacing one?
These are genuinely different projects, and the honest answer to Question 3 usually follows from Questions 1 and 2 rather than from brand preference.
Extending makes sense when the governance layer already works. Keep Informatica, Reltio, TIBCO, or whichever platform is already in place, and add a real-time resolution layer in front of it, so operational systems get a live golden record while the MDM platform keeps handling stewardship workflows and compliance reporting. Nothing about the existing investment gets thrown away, and the batch lag problem disappears without touching the governance model a compliance function has already signed off on.
Replacing makes sense for a narrower set of teams: building from nothing, migrating off a legacy platform that no longer fits, or operating in a single entity domain such as customers, counterparties, or suppliers, where a full multi-domain governance suite is more platform than the problem needs. In that case, entity resolution, golden record assembly, and a query API can cover the requirement without the cost or timeline of a full MDM implementation, deployed in days on AWS rather than a multi-month rollout.
Neither path is more sophisticated than the other. They answer different-sized problems.
Question 4: How many entity domains do you actually need to resolve?
A single-domain problem, resolving one type of entity such as customers, is the case where a lean resolution layer most often covers the whole requirement. A multi-domain problem, resolving customers, suppliers, counterparties, and products all inside one coherent governance model, is the case full MDM was built for.
There is a third shape worth naming separately: multi-party resolution, where identity has to be matched across organisations, not just across departments inside one company. Cofinity-X, the automotive-industry data ecosystem we work with, is a working example. Multiple manufacturers and suppliers each maintain their own systems of record, and no single company’s MDM platform was ever designed to resolve identity across every party’s data at once. That is a resolution problem that sits outside what any one organisation’s MDM implementation can reach, regardless of how mature it is.
Question 5: Where does your data have to live?
Deployment constraints decide more real-world MDM and entity resolution decisions than most vendor comparisons admit. Tilores is AWS-native by default and infrastructure-agnostic by design: the managed path on AWS is the easiest and most common choice, and the same matching engine also runs inside a customer’s own AWS account, another cloud, or fully on-premise for teams whose data cannot leave their own perimeter. Air-gapped environments are supported, and the service is SOC 2 certified.
This matters most once an MDM platform is already anchored to a particular cloud or data centre. A resolution layer that has to run wherever that data already lives is a different proposition to one that only works as an external SaaS call, and it is worth confirming before choosing either path, not after a proof of concept has already assumed a cloud location your data is not allowed to use.
The five questions as a decision table
None of the five questions decide anything alone. Read together, they point toward one of three shapes: extend an existing MDM platform, replace it with a leaner resolution layer, or conclude that full MDM genuinely is the right scope.
| Question | Points toward full MDM | Points toward a resolution layer |
|---|---|---|
| 1. Governance need | Stewardship workflows, manual merge review, audit trail owned by a business team | An automated, correct record is enough |
| 2. Freshness need | An overnight or hourly golden record is acceptable | Operational systems need the current state at query time |
| 3. Existing platform | Governance layer already works and should stay | Building new, or migrating off a legacy platform |
| 4. Entity domains | Multiple governed domains, or cross-organisation resolution needs | One entity domain, one clear owner |
| 5. Deployment constraint | Platform already fits the required environment | Needs to run inside a specific cloud, region, or on-premise |
A team that lands mostly in the left column has a governance problem and full MDM is the right scope. A team that lands mostly in the right column has a matching and freshness problem, and a dedicated resolution layer answers it without the overhead of a governance suite it does not need yet.
FAQ
Can I run entity resolution without a full MDM platform?
Yes, for a single entity domain with no stewardship requirement. A dedicated resolution layer covers matching, deduplication, and golden record assembly through a query API, without the governance workflows a full MDM implementation adds.
Does adding a resolution layer mean replacing our existing MDM platform?
No. A resolution layer can sit in front of an existing platform such as Informatica, Reltio, or TIBCO, feeding it a current, real-time golden record while the platform keeps handling stewardship, survivorship, and compliance reporting.
Why do MDM platforms run entity resolution on a batch schedule?
Most MDM platforms build their golden record on a scheduled job that runs every few hours or overnight, matching the cadence of the stewardship and governance review that already happens on a similar schedule. The trade-off is a golden record that is only as current as the last run.
What is the practical difference in speed between batch and real-time matching?
A batch job surfaces a new or changed record at the next scheduled run, which can be hours away. A real-time resolution layer can make a new record visible in the resolved entity in well under a second, which matters most for fraud checks, underwriting, and any AI agent answering a live question.
How does Cofinity-X illustrate a multi-party entity resolution problem?
Cofinity-X is an automotive-industry data ecosystem where multiple manufacturers and suppliers each maintain their own systems of record. No single company’s MDM platform was designed to resolve identity across every party’s data at once, which is a resolution problem that sits outside what one organisation’s governance layer can reach on its own.
Sources
- What Is Master Data Management?, Informatica, checked 2026-08-26.
- Master Data Management, Wikipedia, checked 2026-08-26.
- What Is AWS Entity Resolution?, AWS Entity Resolution Documentation, checked 2026-08-26.
- Master Data Management: Real-Time Entity Resolution for MDM, Tilores, checked 2026-08-26.
- Build vs Buy: Entity Resolution, Tilores, checked 2026-08-26.
- Deployment Options: Run Tilores Where Your Data Is, Tilores, checked 2026-08-26.
- Pricing, Tilores, checked 2026-08-26.
- API Reference, Tilores Documentation, checked 2026-08-26.
- Cofinity-X Selects Tilores as Entity Resolution Provider, Tilores, checked 2026-08-26.
See what resolved entity data does for your business — and your AI.