Kindly fill up the following to try out our sandbox experience. We will get back to you at the earliest.
Atlan vs Microsoft Purview as a data catalog: source coverage, lineage, classification limits and billing, every claim cited to the vendor documentation.
Updated on
Choose Microsoft Purview if the data you need to describe already lives inside Microsoft. Choose Atlan if your working estate is a cloud warehouse with a transformation layer on top of it, and the people who need the catalog are analysts and engineers who will abandon anything slow. That is the honest split, and most comparisons bury it under a feature grid.
The more useful question is where each one stops, rather than which product wins overall. Purview stops at the edge of what its scanner can read and what each connector is documented to support, and those limits are written down in detail that almost nobody reads. Atlan stops at the edge of its own quality module, which covers three warehouses out of a far longer connector list. Both stop well short of telling you that a table broke last night.
Everything below about either product was read from that vendor's own documentation on 6 September 2026, and the exact pages are listed at the end so you can check any of it. Where our own internal reference disagreed with the documentation, the documentation won, and there are two places in this article where that happened.
Read the table as a decision rule rather than a verdict. The correct answer changes with the shape of your estate and the size of the team that has to run the thing.
| Platform | Buy it when | What it still leaves you to solve |
|---|---|---|
| Decube | You want catalog, column level lineage, quality testing and observability under one subscription, and you are a lean team that cannot staff a governance program. | It is a third product to evaluate in a market where two names arrive on the shortlist by default. You have to justify buying anything at all if your estate is entirely Microsoft. |
| Atlan | Your estate is Snowflake, Databricks or BigQuery with dbt on top, adoption is the problem you are solving, and lineage precision is what makes the catalog credible to engineers. | Quality testing covers three warehouses. Monitoring and alerting on broken pipelines is a separate product. Atlan does not publish list pricing. |
| Microsoft Purview | Your data is Azure, Fabric, Power BI and Microsoft 365, and the value is having one inventory across the tenant with classification and policy attached to it. | Coverage and lineage vary by connector outside Microsoft. Quality is a separate metered workload with its own source list. Billing is consumption based, so the total is a forecast rather than a line item. |
The first thing to get straight is that "Purview" names several things, and a comparison that treats it as a single product will mislead you. Underneath sits the Data Map, the scanning and metadata layer that inventories your estate. On top of the Data Map sit the catalog experiences. There are currently two of those, and they are not the same product.
The older one is the classic Data Catalog, which Microsoft documentation is now explicit about:
Microsoft Purview Data Catalog (classic), Data Health Insights (classic), and Purview Workflow (classic) are no longer taking on new customers and these services, previously Azure Purview, are now in customer support mode.
The current one is Unified Catalog, and it is built around a different organizing idea. Instead of a flat inventory of assets, it asks you to define governance domains, group assets into data products inside those domains, then attach glossary terms, critical data elements, access policies, OKRs, health controls and data quality rules to them. Microsoft documentation describes governance domains as a boundary that aligns the data estate to the organization, and critical data elements as a logical grouping that maps, for example, "CustID" from one table and "CID" from another into a single container.
This matters for a practical reason that has nothing to do with features. Unified Catalog is rolling out by region, and the documentation tells you to check the regional schedule and to upgrade to the enterprise version before you will see it. If someone demonstrated Purview to you and you cannot find what they showed, that is usually why.
It also changes what work the catalog expects from you. Atlan is a catalog you populate by connecting sources. Unified Catalog is a catalog you populate by connecting sources and then modeling your business on top of them. That second step is real work, and it is the step Microsoft bills for.
The most common assumption about Purview is that it comes with the Microsoft agreement you already signed. It does not, and the free tier is smaller than most people picture.
The free version of Microsoft Purview data governance is documented as being in preview. It caps you at 1,000 annotated assets. It supports five sources through live view: Azure Blob Storage, Azure Data Lake Storage Gen2, Azure SQL Database, Azure subscriptions and Microsoft Fabric. It does not include automated scans of a hybrid estate, workflows, business rules, automated application of classifications and terms, Data Estate Insights or Data Policy. You cannot open a support ticket on it, and the documentation reserves the right to clean up an account showing three months of no activity.
Past that, Purview data governance runs on pay as you go billing that took effect on 6 January 2025, and it requires an Azure subscription and a resource group in the same tenant. There are two meters. The first counts unique governed assets per day, and the definition of governed is specific:
Assets that are collected in Data Map but aren't linked to a governance concept don't count as governed assets.
Microsoft's own worked example is a SQL Server with 200 tables where 20 are attached to data products, and only those 20 count. That is genuinely reasonable billing, and it rewards curating rather than hoarding. It also means your bill grows exactly as your governance program succeeds, which is a budgeting shape most teams have not planned for.
The second meter is the Data Governance Processing Unit, which Microsoft defines as 60 minutes of managed compute in three performance options, Basic, Standard and Advanced, with Basic as the default. It runs the compute heavy work: data quality scans and data health controls. The documentation gives worked consumption figures, for example a simple blank check over one million rows on Azure SQL Database consuming 0.02 units, and a high complexity rule over a billion records taking around 2 minutes 51 seconds. Health controls refresh daily by default unless you change the schedule or deactivate individual controls.
We are deliberately not quoting a dollar figure. Microsoft's own pricing page renders its data governance rates only through the regional calculator, so any per asset price you read on a third party comparison page has not been verified against the primary source, and several of them contradict each other. Get the number from the calculator for your own region before you build a business case on it.
Atlan does not publish list pricing at all, so for that product the comparison cannot be made from documentation. The one number in this article that can be read off a public page today is ours.
This is the section that decides most evaluations, and it is the one the competing comparison pages skip entirely. Both vendors publish a coverage matrix. Read it.
Purview Data Map registers a genuinely broad list: Azure services, Amazon RDS, Amazon Redshift, Amazon S3, Cassandra, Db2, Google BigQuery, Hive Metastore, MongoDB, MySQL, Oracle, PostgreSQL, SAP Business Warehouse, SAP HANA, SAP ECC, SAP S/4HANA, Snowflake, SQL Server, Teradata, HDFS, Dataverse, Erwin, Looker, Power BI, Fabric, Qlik Sense, Salesforce and Tableau. The breadth is real and it is a genuine advantage over most catalogs.
The catch is that the capability columns are not uniform. In the same documented table, Amazon Redshift, MongoDB, SAP Business Warehouse, SAP HANA, Qlik Sense, Salesforce and Tableau are all marked as having neither automatic classification nor lineage. Google BigQuery, PostgreSQL, MySQL, Db2 and Cassandra carry lineage but no automatic classification. Snowflake, Oracle and Teradata carry both. If your critical BI layer is Tableau or your CRM is Salesforce, you are getting an inventory entry, not a governed asset with classifications and a lineage graph attached.
Atlan approaches coverage from the other end. Its lineage documentation names the sources it parses SQL for, Redshift, dbt, BigQuery, Snowflake and cloud object storage, the tools it crawls by API, Databricks Unity Catalog, Looker, Power BI and Tableau, and then says you can extend lineage yourself through its open APIs, naming Apache Airflow and Dagster as examples. That is a narrower documented core with a deliberate escape hatch, and the escape hatch is a real answer as long as you have an engineer to use it.
One Purview limit worth knowing before you plan a rollout: the documentation states that the Data Map scanner cannot scan an asset with a forward slash, backslash or hash character in its name, and that the Delta format is not supported directly, so Delta read from storage is parsed as the underlying set of Parquet files and the partitioning columns are not recognized as part of the schema.
Classification is where Purview is usually sold, and it is where the documented behavior diverges most sharply from what a buyer assumes. Microsoft publishes the sampling rules, and they are worth reading in full before you present a classification coverage number to anyone.
For structured files the scanner samples the top 128 rows in each column or the first 1 MB, whichever is lower. For tabular SQL sources it samples the top 128 rows. For documents, the rule is a size ceiling:
For document file formats, it samples the first 20 MB of each file. If a document file is larger than 20 MB, the scanner doesn't perform a deep scan (subject to classification). In that case, Microsoft Purview captures only basic metadata like file name and fully qualified name.
So a 40 MB contract PDF is inventoried, not classified. Nothing in the interface tells the reader of a coverage report that this happened.
The threshold on the other side is just as consequential, and it runs in the opposite direction. For a column in a structured source, Microsoft documents a distinct data threshold as a prerequisite for pattern matching at all:
System classification rules require there to be at least 8 distinct values in each column to subject them to classification. The system requires this value to make sure that the column contains enough data for the scanner to accurately classify it. For example, a column that contains multiple rows that all contain the value 1 won't be classified.
For unstructured files the same documentation says the opposite applies:
For unstructured data formats, such as DOCX files, there's no requirement to meet a condition of eight distinct values. The presence of a single relevant keyword is sufficient for classification.
Put those two rules side by side and you have the practical shape of Purview classification. A structured column with fewer than eight distinct values is invisible to system rules, so a low cardinality but highly sensitive field can pass through unclassified. A Word document containing one relevant keyword gets classified on that basis alone. If your compliance evidence rests on a classification coverage percentage, these are the two sentences that decide what that percentage means.
Three further documented limits belong in the same evaluation. Custom classification rules cannot be applied to document type assets at all, and classifications for those types can only be applied manually. Subsequent scans never remove a classification that was previously detected, even when the rule that produced it no longer applies, so a false positive is sticky. And for encrypted sources the scanner picks up file names, fully qualified names and schema only, so data has to be decrypted before classification works.
Resource sets are the last trap. For delimited and other structured file types in a resource set the scanner deep scans 1 file in 100. For Parquet, Avro and Orc the documented sampling rate is 1 file in 18,446,744,073,709,551,615, which is the maximum value of a long integer and in practice means one file per folder.
None of this makes Purview a bad classifier. It makes it a classifier with published behavior, which is more than most vendors offer. The failure mode is not the product, it is a team that reports "97 percent of assets scanned" without knowing which of these rules produced the number.
This is the row where Atlan wins, and pretending otherwise would cost the rest of this article its credibility. The two products build lineage in structurally different ways.
Atlan documentation states its position plainly:
Atlan captures column-level lineage automatically, tracing every upstream and downstream dependency of a column across warehouses, pipelines, and BI tools.
It builds that three ways: by parsing SQL on Redshift, dbt, BigQuery, Snowflake and cloud object storage, by crawling APIs on Databricks Unity Catalog, Looker, Power BI and Tableau, and by ingestion through its own open APIs for anything else. Atlan is also honest about the ceiling of the first method, in its dbt troubleshooting page: "due to the limitations of SQL parsing, Atlan doesn't guarantee generating lineage for all columns." That caveat is the correct one to expect from anybody parsing SQL, and it is better to see it documented than not.
Purview describes lineage as something the surrounding systems produce and hand over. Its documentation says the goal is to extract movement, transformation and operational metadata from each data system at the lowest grain possible, and that data systems connect to the catalog to generate and report a unique object referencing the physical object in the underlying system. Column or attribute level lineage is documented as a supported granularity, with Azure Data Factory named as an example of a system that can produce a one to one column mapping. But whether you get it at all depends on the connector, and the source table in the same documentation set marks lineage as unavailable for Redshift, MongoDB, SAP HANA, SAP Business Warehouse, Qlik Sense, Salesforce and Tableau.
The practical difference: on Atlan, lineage coverage is a function of how much of your estate it can parse or crawl, and you can extend it yourself. On Purview, lineage coverage is a function of which of your systems report lineage to it, and where they do not, there is no equivalent of a SQL parser filling the gap. That is why an audit trail through a mixed estate is the single most common place a Purview deployment turns out thinner than expected.
This is also the row where our own comparison page concedes to Atlan rather than claiming a win, and we have kept that concession here. Where Decube differs is not raw coverage but the governance sitting on the lineage layer itself, which is lineage changes moving through a structured approval flow, so a change to a documented lineage path is reviewed rather than silently applied.
Neither product lets you finish the buying decision when you sign for the catalog, and this is the section most comparisons get wrong in both directions.
Atlan has a native quality module. Our own internal reference said it covers Snowflake and Databricks only; Atlan's documentation now lists three platforms, and the correct version is worth stating precisely. Data Quality Studio runs on BigQuery, Databricks and Snowflake, and it executes rules through each platform's own machinery: stored procedures on BigQuery, Delta Live Tables on Databricks, and Data Metric Functions on Snowflake. The documented rule set is substantial, covering blank and null counts and percentages, row count, freshness, average, minimum, maximum and standard deviation, duplicate and unique counts, regex, string length, valid values and reference checks, and five reconciliation checks, classified into seven dimensions.
That is a real quality product. The limit is the shape of the list. Three warehouses, in a catalog whose connector coverage is far wider than three. Everything else you catalog in Atlan is outside the quality module.
Purview quality has the opposite shape: a wider source list with sharper internal limits. It supports fifteen sources including Azure Data Lake Storage Gen2, Azure Databricks Unity Catalog, both Synapse variants, Azure SQL Database and Managed Instance, Dedicated SQL Pool, Google BigQuery, Snowflake, Fabric, and Amazon S3, Dataverse and Google Cloud Storage through a Fabric shortcut, plus Oracle and SQL Server for scanning without profiling. It runs on Apache Spark 3.5 and Delta Lake 3.2.1, authenticates only through Managed Identity, and the documentation is explicit that the data source and the Purview account must be in the same Azure region.
Then the limits. The rule catalog is genuinely useful: freshness, unique values, string format match, data type match, duplicate rows, empty and blank fields, table lookup, and custom rules in either Azure Data Factory expression language or Spark SQL, with AI assisted rule suggestions on top. But the documentation carries a note that changes the evaluation:
The freshness rule isn't supported for Snowflake, Azure Databricks Unity Catalog, Google BigQuery, Synapse, and Microsoft Azure SQL.
Freshness is the first check most teams want and the one that catches a stalled pipeline before a dashboard lies to an executive. On Purview it is unavailable on five of the largest platforms the same product otherwise supports. Two further documented constraints sit next to it: custom SQL rules do not support joins and must operate on a single dataset, and you can have a maximum of 200 active data quality rules per data asset, with the scan failing outright if more are active. The documented workaround is to add the same asset to multiple data products or to toggle rules on and off.
There is one more prerequisite chain worth naming, because it surprises teams: on Purview a data asset is not eligible for quality rules until it has been registered and scanned in Data Map, added to a data product, given a source connection, and profiled. Quality is the sixth step of a defined lifecycle rather than a switch you flip on the catalog.
And neither product is an observability tool. A quality rule tells you a value failed a test when the test ran. Knowing that a pipeline did not run at all, that volume dropped by a third overnight, or that a schema changed upstream is a different job, and on both of these platforms it is somebody else's product.
Both vendors now sell the catalog as the thing that makes AI trustworthy, so it is worth checking what is actually documented rather than what is on the landing page.
Atlan documents Atlan AI as generating documentation for tables, views, columns and terms, producing glossary overviews and completeness diagnostics, explaining transformation logic in natural language for assets that carry SQL, and suggesting data quality rules from metadata structure. It also documents a remote MCP server exposing its metadata graph to external tools, naming Claude, ChatGPT, Cursor, Gemini, Codex, Snowflake Cortex and n8n. Admin enablement is required, and some capabilities may need additional licensing.
On the security question, our own reference is out of date and the correction matters for anyone in a regulated sector. It said Atlan AI relies on OpenAI. Atlan's AI security documentation describes a multi provider gateway spanning Anthropic Claude models served through Amazon Web Services, OpenAI GPT models, Google Gemini models and open source models that Atlan hosts itself. The gateway is hosted across the United States, the EU and APAC so tenant data is processed in the closest region, only metadata such as table, view, column, database and schema names is sent to the model, and prompts and responses are not retained in the central control plane, with observability data kept for 30 days. That is a materially different answer to give a risk committee than "it uses OpenAI".
On the Microsoft side the AI story is mostly not in the catalog at all. It is in Fabric. A Fabric data agent is a generally available feature that answers plain English questions over data in OneLake, using Azure OpenAI Assistant APIs, and it respects Purview policies on the underlying sources. Its documented limits are the useful part of the comparison: it requires a paid F2 or higher Fabric capacity, supports up to five data sources per agent, is strictly read only, does not support unstructured data such as PDF, DOCX or TXT files, does not support non English languages, does not let you change the model, caps every response at 25 rows and 25 columns, and fails outright when the data source capacity sits in a different region from the agent capacity.
That is a well governed conversational analytics feature, and it is a good one. It is not a context layer for the whole estate. A dedicated catalog answers a different question: what does this field mean, where did it come from, who owns it, and is it currently trustworthy. An agent scoped to five OneLake sources and 25 rows per answer is not attempting that job, so the two are complements rather than substitutes.
If this comparison has a blind spot, it is that both products leave the same thing unsolved. Atlan gives you the best lineage of the three and a quality module across three warehouses. Purview gives you the widest source inventory and classification with published behavior. Neither tells you that the table broke overnight, which is the moment the catalog either earns trust or loses it. That is the gap Decube is built around: catalog, column level lineage, quality testing and observability under one subscription rather than three purchases.
| Capability | Decube | Atlan | Microsoft Purview |
|---|---|---|---|
| Catalog and discovery | Native. Unified catalog, metadata search, business glossary, custom attributes, verified and deprecated tags. | Native. Built for modern cloud stacks, strongest on Snowflake, Databricks, BigQuery and dbt. | Native, and the broadest source list of the three. Capability per source varies; the classic catalog is in customer support mode and Unified Catalog is rolling out by region. |
| Column level lineage | Yes, with lineage changes routed through a structured approval flow. | Yes. Documented as captured automatically across warehouses, pipelines and BI tools; SQL parsing is not guaranteed to cover every column. | Documented as a supported granularity, but availability depends on the connector, and several major sources are marked as having no lineage at all. |
| Native data quality testing | Yes. No code and custom SQL tests, 12 test types, dynamic thresholding, bulk configuration and alert grouping. | Yes, on three platforms: BigQuery, Databricks and Snowflake. | Yes, on fifteen sources, with freshness unsupported on five major platforms, no joins in custom SQL rules and a 200 active rule ceiling per asset. |
| Native observability | Yes. Pipeline health, freshness, volume, schema change detection and machine learning based anomaly detection. | No. Documentation covers quality rules, not pipeline monitoring. | No. Health controls score your governance posture, not your pipelines. |
| Pricing you can read before a sales call | Yes, published on the pricing page. | No list pricing published. | Partial. The billing model is fully documented; the rates come from a regional calculator. |
On price, ours is the only figure in this article that can be read off a public page today. Decube publishes its pricing at 175 US dollars per user per month on Starter, from 21,000 US dollars a year with a minimum of 10 users, and 225 US dollars per user per month on Growth, from 54,000 US dollars a year with a minimum of 20 users. Whether that is cheaper than a Purview consumption forecast depends entirely on how many assets you govern and how often you run quality jobs, which is the honest answer rather than a comfortable one.
Two things Decube does not claim. It does not have the source breadth of Purview Data Map, and it does not claim to beat Atlan on raw column level lineage. If you want the head to head on the second point, we keep it on a dedicated Atlan and Decube comparison rather than restating it here.
Four situations, four answers, and the reasoning behind each.
Whichever way you go, the test to apply is the same one in every case: pick a number an executive looks at weekly, and try to trace it back to source. If you cannot get from the dashboard to the column to the pipeline that fills it, the catalog you are evaluating has not solved your problem, whatever its feature grid says. That trace, and not the search experience, is what a data catalog is actually for.
Microsoft Purview has the broader source list and attaches classification and policy to what it inventories, which makes it the right answer for an estate that is mostly Azure, Fabric, Power BI and Microsoft 365. Atlan has the stronger lineage: its documentation describes column level lineage captured automatically across warehouses, pipelines and BI tools, built from SQL parsing, API crawling and its own open APIs. The trade off is that Purview capability varies by connector, with several major sources documented as having neither automatic classification nor lineage, while Atlan's quality module covers three warehouses out of a much wider connector list. Neither product monitors pipelines, so alerting when data breaks is a separate decision on both.
No. There is a free version of Microsoft Purview data governance, but Microsoft documents it as being in preview, capped at 1,000 annotated assets, and limited to five sources through live view: Azure Blob Storage, Azure Data Lake Storage Gen2, Azure SQL Database, Azure subscriptions and Microsoft Fabric. It excludes automated scans of a hybrid estate, workflows, business rules, automated application of classifications and terms, Data Estate Insights and Data Policy, and it carries no support entitlement. Beyond that, data governance runs on pay as you go billing that took effect on 6 January 2025, with one meter counting unique governed assets per day and another counting Data Governance Processing Units for quality and health jobs.
Metadata management is the underlying discipline of collecting, storing and maintaining technical and business metadata about your data assets. A data catalog is the product people use on top of it: the search, the business glossary, the ownership, the lineage graph and the trust signals that let someone find a table and decide whether to rely on it. Microsoft draws this line inside its own architecture, where the Data Map is the metadata layer that scans and stores, and the catalog is the experience built on top of it. In practice the useful question is not which label a vendor uses but whether the tool answers four things about a field: what it means, where it came from, who owns it, and whether it is currently trustworthy.
Yes as a documented granularity, but availability depends on the source. Microsoft documents column or attribute level lineage as one of its lineage granularities, using the example of Azure Data Factory copying a column one to one from an on premises environment to the cloud. The important qualifier is that Purview lineage is reported to it by the systems that support reporting it. Microsoft's own data source table marks lineage as unavailable for Amazon Redshift, MongoDB, SAP HANA, SAP Business Warehouse, Qlik Sense, Salesforce and Tableau, and there is no SQL parsing layer filling those gaps. Check the coverage table for your specific sources before assuming an end to end trace is possible.
No. Atlan Data Quality Studio is documented as supporting three platforms, BigQuery, Databricks and Snowflake, and it executes rules using each platform's own machinery: stored procedures on BigQuery, Delta Live Tables on Databricks and Data Metric Functions on Snowflake. The rule set itself is broad, covering blank and null checks, row counts, freshness, statistical measures, uniqueness and duplicates, string validations and reconciliation checks across seven quality dimensions. But anything you catalog in Atlan outside those three warehouses sits outside the quality module, and pipeline monitoring is a separate product in either case.
They answer different questions. A Fabric data agent is a generally available conversational analytics feature that lets people ask plain English questions over data in OneLake using Azure OpenAI Assistant APIs, and it honors Purview policies on the underlying sources. Its documented limits define its scope: a paid F2 or higher Fabric capacity, up to five data sources per agent, read only access, no support for unstructured data such as PDF, DOCX or TXT files, no non English languages, no ability to change the model, and every response capped at 25 rows and 25 columns. A dedicated context layer is doing something wider: describing what every field means, where it came from, who owns it and whether it is currently trustworthy, across the whole estate rather than a scoped set of sources. Treat them as complements, and do not expect a scoped agent to be the governance layer for an AI program.
If your data genuinely lives inside Microsoft, choose Purview and stop looking. The metadata is already in the tenant, classification and policy attach to it, and buying a second catalog to describe the same assets adds cost without adding an answer. Reopen the question when one of three things becomes true: a critical source sits on the list Microsoft documents as having no lineage and no automatic classification, your quality program needs freshness checks on Snowflake, Databricks Unity Catalog, BigQuery, Synapse or Azure SQL where the Purview freshness rule is documented as unsupported, or you need to know that a pipeline broke rather than that a rule failed. Any of those three is a reason to evaluate a dedicated platform alongside it.
First step to AI Readiness
Table of Contents
Sneak peek from the data world.
Bring lineage, quality, governance, and AI together in one platform—so your teams and AI agents can act with confidence.
_For%20light%20backgrounds.svg)
.svg){kind=small}
.webp)