Microsoft Purview Data Governance: Pricing, Lineage Limits and Alternatives

What Microsoft Purview does well

Purview is not really one product, and that is the first thing to understand about it. Microsoft groups five separately metered families under the name: Data Governance, Data Map, Data Security, Data Compliance and On-Demand Classification. Together they cover cataloging, scanning, classification, sensitivity labels, data loss prevention, insider risk, communication compliance, retention, audit and eDiscovery, across Azure, Microsoft 365, Fabric and a long list of third-party sources.

If your organization already runs on Microsoft, that breadth is the whole argument. Purview applies a sensitivity label in SharePoint and honors it in Power BI. It feeds audit and eDiscovery for the same tenant your email lives in. It ships connectors for Azure Data Factory, Synapse, Azure SQL, Databricks Unity Catalog, Snowflake, BigQuery, Oracle, Db2, Hive, PostgreSQL and MySQL. No independent vendor is going to match that reach into Microsoft 365, and it would be dishonest to pretend otherwise.

It is also, for a compliance team, the cheaper answer by a wide margin. Buying separate tools for labeling, DLP, retention and eDiscovery costs far more than adding Purview meters to an Azure bill you already pay. Where it gets argued about is the narrower engineering job: lineage and impact analysis across a warehouse that is not primarily Azure.

What Microsoft Purview costs, read from the Azure retail price API on 30 August 2026

Purview is unusual among governance platforms in that it does publish real prices, and they are machine-readable. The Azure retail price API is public, needs no key, and returns every Purview meter with its rate, unit and effective date. We queried it on 30 August 2026 and got 712 records across 23 regions. Here is the full US East set, deduplicated.

Read from the public Azure retail price API on 30 August 2026, region East US, US dollars. Rates are list prices before Enterprise Agreement or CSP discounting.

Three things in that table are worth pulling out.

The catalog charge compounds faster than buyers expect. At $0.0165 per governed asset per day, one asset costs $6.02 a year. A 10,000-asset estate is $60,225 a year in asset charges alone, before a single processing unit. That number is not far off the $60,000 Alation lists on AWS Marketplace, and a 30,000-asset estate at $180,675 passes the $170,000 Collibra publishes. The per-unit price is small enough to feel harmless and the multiplier is a calendar year, which is exactly the shape that surprises people at renewal. We work through the arithmetic in detail in our breakdown of Microsoft Purview pricing.

A processing unit costs $15, $60 or $240 depending on which word precedes it. Basic, Standard and Advanced are all sold as one Data Governance Processing Unit, in the same unit of measure, with a 16x spread between the cheapest and the dearest. Which tier your scans and classification jobs consume is the single biggest lever on a Purview bill, and it is not something the pricing page makes obvious.

Data Map is down to one meter. Comparison articles still quote the old elastic Data Map capacity-unit and scanning vCore rates. As of our reading on 30 August 2026 the Microsoft Purview Data Map product returns exactly one meter across all 23 regions in the API, Advanced Resource Set vCore at $0.21 per hour, effective 1 April 2026. If a competitor comparison quotes you a Data Map capacity unit price, check the date on it.

Rates were identical in every region we checked, so there is no cheaper geography to deploy into.

Where Purview lineage stops: the connector table Microsoft publishes and most comparisons skip

Purview publishes a capability matrix for every source it supports, with a column headed Data lineage. It is the most useful page in the documentation and almost nobody reads it before buying. Here is what it says about the sources a modern analytics stack actually runs on.

Summarized from the Microsoft Purview connector overview and per-source documentation, read 30 August 2026. Verify against current Microsoft documentation before you rely on it.

The Redshift row is the one that ends evaluations. Microsoft marks Amazon Redshift as No in every column of that table, lineage included. If a meaningful part of your warehouse is Redshift, Purview will not draw its lineage at all, and no amount of tuning changes that.

The Power BI limit is narrower than it looks. Microsoft states it plainly: column level lineage and transformations, other than Dataflows, are supported when using Azure SQL Database as the source, and other sources are currently not supported. So a Power BI report reading from Snowflake, BigQuery, Databricks or Redshift gets artifact-to-artifact lineage, dataflow to dataset to report to dashboard, but no column-level trace back through the report into the warehouse column that fed it. That is precisely the question people open a lineage tool to answer, and it is the reason teams pair Purview with a warehouse-native tool. We cover the same ground from the Power BI side in Power BI data lineage and on our Power BI lineage page.

Snowflake lineage is static, and scans are full-only. The Snowflake connector documentation describes what Purview fetches as static lineage on asset relationships among tables, views, streams and stored procedures, generated from object definitions rather than from executed queries. The same page lists Incremental Scan as not supported, so every scan is a full scan. Stored procedure lineage is also documented as unsupported for procedures written in Java, Python or Scala, and for SQL using EXECUTE IMMEDIATE with the query held in a variable.

The practical consequence is that a transformation expressed as an ad hoc CREATE TABLE AS SELECT, or inside a Python stored procedure, or through a dbt run, does not appear. Lineage built from query history sees all of it, because it reads what actually ran rather than what was declared. That difference is the whole reason column-level lineage from query logs exists as a category, and it is covered in more depth in Snowflake column-level lineage.

One documented behavior with a billing consequence nobody mentions

Buried in the limitations section of the Snowflake connector page is this sentence: when you delete an object from the data source, the subsequent scan does not automatically remove the corresponding asset in Microsoft Purview.

On its own that is a housekeeping annoyance. Dropped tables linger in the catalog, search results fill with objects that no longer exist, and someone has to clean up by hand. Put it next to the meter, though, and it is worth a line item in your estimate. Data Governance bills the Data Catalog Standard Asset meter per asset per day. A catalog that retains assets after the underlying objects are gone is a catalog whose billable asset count only moves in one direction unless somebody actively prunes it.

We would not overstate this. Microsoft does not publish a statement that orphaned assets remain billable, and the exact behavior may depend on your scan configuration and cleanup policy, so treat it as a question to put to your account team rather than a settled fact. But it is the right question to ask, and it is the sort of thing worth checking against your own invoice on an estate that churns tables. If you are running the numbers for a Purview deployment, ask specifically how the billable asset count is derived and whether it is reconciled against sources.

Classic Data Catalog and Unified Catalog: two lineage experiences in one product

Purview is mid-migration, and this catches evaluators out. Microsoft now runs a classic Microsoft Purview Data Catalog and a newer Unified Catalog in the Microsoft Purview portal, and lineage is documented separately for each. The classic lineage concept page opens by saying it describes lineage in the classic Data Catalog and then redirects readers to the Unified Catalog data-product documentation for the newer experience.

That matters for two reasons when you are comparing tools. First, screenshots, tutorials and third-party reviews written before the split may be describing an interface you will not see. Second, the two surfaces are organized around different objects: the classic catalog is asset-centric, while Unified Catalog is organized around governance domains and data products, with lineage shown on the data asset details page underneath a data product. If your evaluation criteria were written against classic Purview, re-run them against the portal you will actually be given.

There is a live operational item here too. Microsoft has told Purview customers using the Snowflake Data Map connector to move off basic authentication to key pair authentication, because Snowflake is disabling basic auth. The documented path was to set the Purview service user to type LEGACY_SERVICE before the end of July 2026, and Microsoft notes that creating new LEGACY_SERVICE users is not permitted from August 2026. That deadline has now passed. If you inherited a Purview Snowflake scan configured on basic auth, check it.

If you are on Databricks and weighing Purview against the catalog you already have, we compare the two head to head, meter by meter, in Unity Catalog vs Purview.

Microsoft Purview competitors, and which one replaces which part

Purview competitor lists are usually incoherent because Purview covers several categories at once. Sorting the field by what each tool actually replaces makes the shortlist much shorter.

Two rules of thumb make this decision faster. If your problem is Microsoft 365 compliance, labeling, retention, DLP, insider risk or eDiscovery, nothing on that list replaces Purview and you should stop shopping. If your problem is the analytics warehouse, the honest comparison is against Collibra and Alation for the governance program, Unity Catalog or Snowflake Horizon if you live on one platform, and lineage-first tools for impact analysis. The whole field is laid out in our data governance tools and data catalog tools comparisons.

The open source route deserves a mention because it is the one most often dismissed too quickly. OpenMetadata and DataHub both do warehouse cataloging and lineage with no license cost. You pay in engineering time instead, which for a small team is usually the more expensive currency, but for a platform team with capacity it is a real option.

Where Datatrail fits, and where it does not

Datatrail is not a Purview replacement and we are not going to claim it is. We do not do sensitivity labels, DLP, retention, insider risk or eDiscovery, and we have no coverage of Microsoft 365 at all. If those are your requirements, buy Purview.

What we do is one job. Datatrail connects read-only to Snowflake, BigQuery, Databricks or Redshift, parses the query history and the dbt graph, and builds column-level lineage from what actually ran. Because the graph comes from executed queries rather than object definitions, it follows a CREATE TABLE AS SELECT, a dbt model, an ad hoc backfill and a Python procedure the same way. From that graph we compute impact analysis: given a column you are about to change or drop, every downstream table, model, exposure and dashboard that reads from it, listed by name, before you merge. The freshness and schema change alerts run on the same graph, which is what makes an alert tell you who is affected instead of just that something moved.

The two coexist perfectly well, and in Microsoft-heavy shops they usually do. Purview is the system of record for governance and compliance across the tenant. A lineage tool answers the engineering question underneath it: if I change this column tomorrow, what breaks. You can see the whole graph on your own warehouse in an afternoon, with no Azure subscription, no scan schedule and no rollout, and the price is on the pricing page. For the broader landscape, start with our data lineage tools comparison.