Back to blog
PrimentraPrimentra
·April 20, 2026·8 min read

MDM is not a data catalog. And a catalog is not MDM.

Home/Blog/MDM is not a data catalog. And a catalog is not MDM.
Data catalog
Reads and describes
dbo.CustomersPII
fact.Salesfinance
stg.SupplierFeedrestricted
MDM tool
Writes and governs
C-4821 · Acme Corpapproved
C-4822 · Northwind BVpending
C-4819 · Globex Ltd.approved
Different jobs · different tools · both legitimate

A customer I spoke with last month told me his Microsoft rep had spent the better part of an hour explaining how Purview was the natural path forward for his MDS workload. He walked out of the meeting convinced. A week later he tried mapping his MDS entities onto Purview concepts and could not. There was no place for his approval workflows. No integration views. No golden record concept. Just a crawler, a search bar, and some lineage graphs.

He was not doing anything wrong. He had been handed the wrong tool and told it was the right one. It happens constantly.

One describes data. The other creates it.

The simplest way to keep these straight: a catalog is a reader, an MDM tool is a writer.

A catalog connects to your databases, warehouses, files, and BI tools. It inventories what exists: tables, columns, reports, dashboards. It classifies sensitivity, tracks lineage, and makes the whole estate searchable. It does not change the data. It holds a mirror to it.

An MDM tool is where stewards author a narrow set of records. You define what a customer looks like, who owns the record, what validation applies, and who has to approve a change. The MDM system is the source of truth for those records, and every other system subscribes to it. Nothing happens to a governed record unless it happens in MDM first.

These are not two flavors of the same product. They operate in opposite directions.

Data catalogMDM tool
Primary jobDescribe data that already existsAuthor the data that other systems reference
DirectionRead-only — crawls sources, captures metadataRead-write — records are created, edited, approved here
ScopeEvery table, column, report, dashboard in the estateA handful of governed entities — customers, products, suppliers, cost centers
UsersAnalysts, data engineers, compliance officersData stewards, reviewers, business owners
OutputSearch, lineage graphs, sensitivity tagsGolden records, approval history, integration views
Question answered"Where does this field come from?""What is the correct value, and who approved it?"

What a catalog does well

I do not want to undersell catalogs. For the right job, they are excellent.

When an analyst needs to find a table that holds monthly revenue by region, a catalog earns its license fee in a single search. When a compliance team has to map where personal data lives across 200 source systems for a GDPR article 30 record, a catalog does that work in hours instead of weeks. When a data engineer wants to understand what breaks if a column gets renamed, a lineage graph answers the question without reading a single pipeline.

Discovery, classification, lineage, sensitivity scanning. Real problems, and catalogs solve them properly. If your estate has grown past the point where anyone remembers what lives where, a catalog pays for itself.

What a catalog cannot do

A catalog can tell you there are three customer tables across your estate. It cannot tell you which one is correct. It can tag a column as holding supplier bank accounts. It cannot prevent someone from silently editing one of those accounts at two in the morning. It can show you that a BI report depends on the cost center hierarchy in the ERP. It cannot keep that hierarchy in sync with the one in the BI tool.

That is not a shortcoming. Catalogs were never meant to do those things. They describe what is already there. Keeping it tidy is a different discipline.

The specific gaps most MDS users run into when they try to force a catalog into an MDM shape:

No authoring UI
A catalog shows you what exists. It does not provide a place to create or edit a record. There is no "new customer" form in a catalog because that is not what it is for.
No approval workflow
The entire point of governed master data is that a steward proposes a change, a reviewer inspects it, and only approved changes go live. Catalogs have no concept of a changeset or a review gate.
No integration views
Downstream systems need a stable published view of the master: a SQL view, a REST endpoint, something they can subscribe to. Catalogs publish metadata about data. They do not publish the data itself.
No golden-record model
Merging two supplier records, picking survivor values, preserving cross-references. That is core MDM work. A catalog can tag duplicates. It cannot resolve them.

Why the confusion keeps happening

Part of it is vendor positioning. “Data governance” has become a catch-all phrase that covers both disciplines, and a sales deck that includes the phrase can plausibly end up in front of either audience. If a customer says “I need to govern my master data” and a vendor sells a catalog, nobody flags the mismatch in the room. The word governance papers over the gap.

Part of it is Microsoft. When MDS was quietly deprecated and then removed entirely from SQL Server 2025, the official migration guidance pointed at Purview. But Purview does not author data. It catalogs it. Shipping MDS customers to Purview is like telling someone whose word processor was cancelled that the file explorer still works.

Part of it is scope. A catalog covers thousands of tables. An MDM tool governs a few dozen entities. Numerically the catalog looks bigger, so it seems like the superset. It is not. Coverage of the inventory is not the same as authorship of the records.

What a real stack looks like

In most mid-to-large organizations I work with, the final picture is not catalog or MDM. It is both, doing different jobs.

The MDM tool owns the handful of entities that have to be consistent across the business: customers, products, suppliers, cost centers, legal entities, chart of accounts. Stewards work in MDM. Approvers work in MDM. Downstream systems subscribe to MDM through integration views or APIs. When someone asks “what is the correct address for supplier S-4821,” the answer lives in MDM.

The catalog indexes everything else, including the MDM system itself. Analysts use it to find data. Compliance uses it to prove coverage. Engineers use it to trace lineage. When someone asks “where does this column come from,” the answer lives in the catalog.

Neither tool fights the other, because they are answering different questions.

The test question

If you are sitting in a vendor meeting and you cannot tell whether the product is a catalog or an MDM tool, ask one question: can I create a new customer record here, with an approval step, and distribute it to three downstream systems?

If the answer involves lineage diagrams, sensitivity tags, or “we can integrate with your existing MDM,” you are looking at a catalog. That is fine. It may be exactly what you need. But do not buy it expecting to retire MDS.

If the answer is “yes, here is the entity model, here is the approval workflow, here is the integration view,” you are looking at an MDM tool. That is the replacement for MDS. Whether it is the right one is a separate question, but at least it is the right category.

Common questions

What is the difference between a data catalog and a master data management tool?

A data catalog describes data that already exists. It crawls source systems, captures metadata, classifies sensitivity, and lets users search for tables or fields. It is a read-only discovery layer. An MDM tool authors the data itself — the system of record where customers, products, suppliers, and cost centers are created, edited, reviewed, and approved. Catalogs document the landscape. MDM tools shape it.

Can Azure Purview replace Microsoft MDS?

No. Purview is a catalog and governance platform, not an MDM tool. It indexes where data lives and tracks lineage, but it does not provide the editing workflows, approval chains, integration views, or golden-record authoring that MDS users relied on. Replacing MDS with Purview leaves you with a catalog that describes your master data problem without solving it.

Do I need both a data catalog and an MDM tool?

Most mid-to-large organizations end up with both, but for different reasons. MDM governs the handful of entities that must be consistent across systems. A catalog indexes the much larger estate of warehouses, reports, and lakes so analysts can find data and demonstrate lineage. They complement each other. Neither replaces the other.

Where does a catalog fall short for master data use cases?

A catalog can tag a column as containing customer data. It cannot enforce that two systems agree on who the customer is. No approval workflow, no segregation of duties, no golden record, no integration views that downstream systems can consume. Asking a catalog to govern master data is asking a library index to write the books.

Looking for an actual MDS replacement?

Primentra runs on SQL Server, authors the records your systems depend on, and publishes them through integration views the rest of your stack can consume directly. A catalog can sit alongside it for discovery, but the authoring, approvals, and golden records belong in an MDM tool. The 60-day trial includes everything.

Start free trial →Try the demo →

More from the blog

Survivorship rules: picking the winner when two master records disagree9 min readMaster data decay: why your MDM goes stale in four months (and how to stop it)7 min readMaster data during mergers and acquisitions: the integration problem nobody budgets for9 min read

Ready to migrate from Microsoft MDS?

Join the waitlist and be the first to try Primentra. All features included.

Download Free TrialTry DemoCompare MDM tools