Every data governance program starts small. You catalog a few critical systems, settle the definitions people argue about, assign owners, and prove the approach works. Then it grows. More sources, more domains, more assets that someone somewhere depends on. Growth is the whole point, because a governance program that stays small has not succeeded at anything.
Microsoft Purview punishes that growth directly. Under its current data governance model, published on Microsoft's Azure Purview pricing page, you pay roughly $0.50 per governed asset each month, plus separate processing charges for data quality and health management. The rate reads as small. The arithmetic stops reading as small quickly.
Which leaves data leaders with an awkward question before signing anything. The useful figure is never what Purview costs at today's coverage. It is what the program costs at the coverage you are actually aiming for, and whether the pricing model gives your team a quiet reason to aim lower.
What Microsoft Purview costs, and what actually triggers the meter
Purview has no single price, which is why cost questions about it rarely get a clean answer. Two separate billing systems run underneath it, and a data governance buyer only pays serious money into one of them.
The two layers you pay for
The first layer is per-user licensing. Purview's security and compliance capabilities ship inside Microsoft 365 E5 at $60 per user per month, or through the Purview Suite add-on at $12 per user per month for organizations already on E3.
That layer covers the Microsoft 365 estate. Your Snowflake warehouse, your on-premises Oracle instances, and your Databricks lakehouse fall outside it entirely. Governing those sources bills through the second layer, which is metered consumption.
Most enterprise deployments pay both, and the second layer is where governance budgets get decided.
What the governance meters cost
Microsoft publishes the data governance meters separately from the security and compliance ones. Four matter for a catalog and governance program:
|
Meter |
Rate |
|
Unified Catalog, governed assets |
$0.0165 per asset per day, roughly $0.50 per month |
|
Data Governance Processing Unit, Basic |
$15 per DGPU |
|
Data Governance Processing Unit, Standard |
$60 per DGPU |
|
Data Governance Processing Unit, Advanced |
$240 per DGPU |
One DGPU represents 60 minutes of managed compute. Data quality rules and health controls default to the Basic tier, which keeps unit costs low while the number of runs climbs.
Discovery is not the same as governance
Here is the mechanic that determines your bill. Microsoft separates the Data
Map from the Unified Catalog. The Data Map scans sources and builds a metadata inventory. The Unified Catalog is where assets get curated, given business context, and tied to data products, quality rules, and critical data elements.
An asset only becomes billable when it crosses into that second state.
Did you know? Scanning metadata into the Purview Data Map carries no governed-asset charge. Billing begins when an asset is linked to a governance concept such as a data product or a critical data element.
Knowing an asset exists costs nothing. Actively governing it does. The line between those two states is now an economic one, which raises an uncomfortable question about what exactly you are being charged for.
What Purview costs at 10,000 governed assets versus 1 million
Unit prices tell you almost nothing about program cost. What matters is the shape of the curve as governance coverage grows, because growth is what a working program does.
Governed asset cost as coverage grows
Microsoft publishes a worked example on its Azure Purview pricing page: an organization with 500 assets in the Data Map, 200 of them governed in the Unified Catalog, pays $100 per month. That gives a clean per-asset rate to extend.

*Illustrative extrapolation from Microsoft's published governed-asset example. Actual customer pricing can differ based on geography, contracts, discounts, configuration, and future pricing changes.
A mid-sized enterprise cataloging its analytical estate lands somewhere in the first two rows. A large organization governing across finance, operations, customer, and product domains reaches the middle rows without doing anything exotic.
What data quality processing adds on top
Governed assets are only part of the bill. Data quality and health management meter separately through DGPUs, and profiling is compute-intensive by nature.
Microsoft's own documentation gives the arithmetic: 100 data management rules running in a single day, at 0.02 DGPU per run, consume two DGPU. On the Basic tier, that is $30 for the day.
Pro tip: Model quality processing is based on run frequency, not rule count. One hundred rules running daily costs roughly thirty times what the same rules cost running monthly. Cadence, not coverage, drives this meter.
Run those rules daily across a large estate and the charge stops being incidental. It becomes a standing line item sitting alongside the asset charge, growing with the same coverage decisions.
Why this is the wrong incentive for governance

Put yourself in the budget seat. Discovery has surfaced 500,000 assets across the enterprise. Do you govern all of them? The most important 100,000? Do you stop at 30,000 and revisit next fiscal year?
That question should be answered by risk, regulation, and business value. Under a metered model, the finance team has a legitimate reason to answer it with a number instead.
Consumption pricing is not a flaw in itself. It fits infrastructure well, where storing more, computing more, and transferring more genuinely should cost more. Governance works differently. Its purpose is to increase the share of enterprise information that is understood, owned, trusted, and protected. When each expansion adds consumption, the rational move becomes governing less, not because the data fails to warrant governance, but because governance itself has become the metered activity.
At OvalEdge, we believe the answer to a growing data estate is more automation, not less governance. Software should never create a financial reason to leave important assets outside the program.
What modern governance requires, and what Purview delivers
Cost is only half the story, and stopping there would be a cheap argument.
What a mature governance program has to manage
Governance stopped meaning "scan my databases and give me a searchable catalog" some time ago. A program that holds up under audit and supports AI has to carry ten distinct disciplines at once, each with its own owners, tooling, and failure modes.

The operating burden matters as much as the feature list. Someone has to curate metadata, reconcile business definitions that three teams define differently, identify owners for assets nobody claims, and decide which quality rules belong where. Traditionally that work is manual, and it scales with the number of assets rather than with the size of the team.
The better question to ask
Purview is not a thin catalog, and treating it as one would misread the product. Microsoft documents governance domains, data products, glossary terms, critical data elements, data quality, data health controls, access policies, and lineage, alongside AI-generated quality rule recommendations and AI-assisted profiling. Judged as a feature set, it is a serious governance platform.
Which is exactly why a feature comparison is the wrong evaluation. Both platforms can catalog, trace lineage, and enforce quality rules. The difference shows up later, in how much of the estate you can bring under real governance and whether the operating model lets you keep expanding.
OvalEdge expert insight: Feature checklists rarely decide governance outcomes. What decides them is how much of your estate reaches real governance, and whether your operating model lets the program keep growing.
At OvalEdge, that growing estate becomes part of an Enterprise Context Graph (ECG), a connected record of what data means, who owns it, and how it's used, that gets more valuable as coverage expands instead of more expensive.
So the question worth asking is not whether a platform has governance capabilities. It is what happens to your effort and your bill when you apply those capabilities across the whole enterprise.
How AI agents change the cost of governing at scale
If manual effort is what makes comprehensive governance expensive, the interesting question is whether that effort can be removed rather than metered.
From AI-assisted to AI-performed
Most governance platforms now ship an AI assistant. It suggests a description, drafts a definition, recommends a quality rule. Useful, but the human still does the work and the assistant makes it slightly faster.
The more consequential shift is different. It is AI performing the governance work itself while people make the decisions. That changes the unit economics of the program rather than the ergonomics of the screen.
The traditional model versus the agentic model

The difference is not who uses the software. It is who does the work. Under the traditional model, every task scales with asset count, so doubling the estate roughly doubles the effort. Under an agentic model, the judgment stays human, and the labor does not.
The six OvalEdge governance agents
OvalEdge assigns that work to specialized agents, each answering one governance question:
|
Agent |
Question it answers |
|
APEX |
What should we govern? |
|
CURO |
How should it be curated? |
|
LINGO |
What business concepts already exist? |
|
HELM |
Who should own it? |
|
LITMUS |
What quality controls should exist? |
|
NOTARY |
What can be certified? |
Every recommendation goes to a human for review before it becomes governance.
What changes when agents do the analysis
The difference is easiest to see in the tasks that consume governance teams today.
Instead of analysts manually researching thousands of assets to decide what deserves attention, agents analyze usage, lineage, and sensitivity to recommend where governance should focus. Instead of interviewing dozens of people to surface the four competing definitions of "active customer," AI examines existing metadata, reports, and calculations to find the conflicts. Instead of engineers hand-writing quality rules per table, controls get recommended from observed data behavior. Instead of hunting for owners asset by asset, likely owners and stewards surface from access and usage patterns.
Pro tip: When evaluating governance automation, ask what percentage of recommendations get approved without edits. Automation that generates work for reviewers has moved the effort rather than removed it.
The economic point sits underneath all of it. Headcount should not grow linearly with asset count. Automation should keep lowering the marginal effort of governing the next asset, so that expanding coverage gets cheaper per asset rather than more expensive. That is the opposite of what a per-asset meter produces.
Govern everything, but not everything equally
None of this means every asset deserves every control. Applying full governance uniformly across an estate would waste effort on data nobody queries, and no serious program does it.
Four tiers of governance depth
Depth should vary with what the data actually warrants:

|
Data tier |
Governance depth |
|
High-risk data |
Catalog, glossary, ownership, lineage, quality, privacy, access control, certification |
|
Important analytical data |
Catalog, ownership, lineage, quality, business context |
|
General enterprise data |
Catalog, classification, ownership |
|
Low-value or technical data |
Discovery, basic classification |
Regulated customer records, financial reporting inputs, and anything feeding an executive decision belong in the top tier. Staging tables, logs, and system-generated intermediates sit at the bottom, where knowing they exist is usually enough.
What should drive depth, and what should not
The inputs that belong in this decision are business value, risk, sensitivity, usage, regulatory exposure, lineage impact, and whether AI systems consume the data.
The input that does not belong is the incremental price of switching governance on.
That distinction is the whole argument compressed. Tiering governance by what data warrants is sound practice. Tiering it by what the meter charges produces a different answer, and the gap between those two answers is precisely the cost of a metered model.
At OvalEdge, we believe depth of governance should follow business value, risk, sensitivity, and regulation. It should never be decided by the incremental price of turning governance on.
License-based versus consumption-based pricing
Two pricing models produce two different questions, and your team ends up asking whichever one the contract encourages.
The two questions each model produces
-
Consumption-led governance asks: which assets can we afford to govern?
-
Automation-led governance asks: how much of the enterprise can we govern intelligently?
Both are reasonable questions. Only one of them makes governance coverage a quarterly budget negotiation.
Which question you end up asking is decided by the contract, not the philosophy. A metered model makes automation-led thinking hard to practice, because every asset an agent brings under governance still shows up as more consumption. A license-based model removes that link.
How the two models compare
|
License-based |
Consumption-based |
|
|
What sets your price |
Connectors, capabilities, users |
Assets, scans, processing |
|
As governance expands |
Predictable within licensed scope |
Grows with governance activity |
|
Budget predictability |
Established upfront |
Depends on future consumption |
|
Forecastable at signature |
Yes |
Based on estimated usage |
|
What it encourages |
Govern more |
Manage consumption |
Consumption genuinely suits some situations. If your governance scope is narrow and stable, your estate sits mostly inside Microsoft 365, and you prefer variable spend to committed spend, metering is a reasonable fit. The model becomes difficult when coverage is meant to expand, which describes most programs that are working.
How OvalEdge prices governance
OvalEdge sets price from three inputs, all agreed before you sign.
-
Connectors. One technology at one IP address. A single database instance counts as one connector regardless of how many databases, schemas, or tables sit inside it.
-
Governance add-ons. Capabilities such as automated lineage, data quality, or access governance, attached only to the connectors that need them.
-
Users. Author users who build and manage governance are licensed. The base license includes 1,000 reader users, with further packages available as adoption spreads.
The consequence matters more than the mechanics. Cataloging more assets inside a connector you already license does not change what you pay. Coverage decisions stay governance decisions, made on risk and value, without a finance conversation attached to each one.
Platforms like OvalEdge establish pricing upfront on connectors, capabilities, and users, so the number you sign is still the number you can forecast three years later. You can see how that model works on the OvalEdge pricing page.
How to evaluate governance pricing before you commit
The evaluation question most buyers ask is what a platform costs today. That number is the least useful one available, because it describes a program at its smallest.
Why AI raises the stakes
People compensate for poorly governed data constantly, and mostly without noticing. They know whom to call about a suspect number. They remember that Finance counts "active customer" differently from Marketing. They know which of the four revenue dashboards the CFO actually trusts, and that a badly named column still holds the right values.
AI systems carry none of that. An agent querying enterprise data has no colleague to check with and no memory of which definition won the argument in 2023. It needs the context made explicit: definitions, relationships, ownership, quality signals, lineage, policies, certification status, and access rules. Ungoverned data does not become a slower answer for AI. It becomes a confident wrong one.
That creates a collision worth naming. AI raises the need for broad, deep governance at precisely the moment a metered model raises the cost of supplying it. The two forces pull in opposite directions, and the pull gets stronger as AI adoption spreads.
The full cost of running governance
A defensible evaluation models the program at the coverage it is aiming for, not the coverage it starts with. Run your own estate at 10,000 governed assets, then 30,000, then 100,000, then whatever your full analytical footprint actually holds.

Then add the full operating cost, which runs well past the license line.
OvalEdge expert insight: The useful budgeting question is not what a platform costs today. It is what your economics look like at the coverage level your governance program is actually aiming for.
Which leaves one question to carry into every vendor conversation. Does this platform make us want to govern more data, or less?
Conclusion
The answer to that question should not depend on a rate card. Governance decisions belong to risk, regulation, and business value, and a pricing model that quietly overrules them is solving the wrong problem.
The alternative is not governing everything to the same depth, which would waste effort nobody has. It is discovering broadly, prioritizing intelligently, automating the repetitive analysis, applying governance according to what each asset warrants, and keeping humans on the decisions that need judgment. Agents handle the research. People approve the outcomes.
Data estates will keep growing, and AI will keep raising what it costs to leave parts of them ungoverned. The response to that cannot be to govern less. It has to be to govern more while automating more, so the marginal cost of the next thousand assets falls instead of climbing.
Worth modelling your own numbers before you commit to either model.
Book a demo, and we'll walk through what governance costs across your estate, and how OvalEdge’s Enterprise Context Graph turns that coverage into context your teams and your AI systems can actually trust.
Frequently Asked Questions
Everything you need to know about this topic