Unity Catalog Alternative: Databricks Unity Catalog Lineage Limits and Pricing

What Unity Catalog actually is, and why a Databricks team should use it

Unity Catalog is not an add-on you evaluate against other catalogs the way you would evaluate Collibra against Alation. It is the governance substrate of the platform. Databricks documentation puts it plainly: when enabled for a workspace, Unity Catalog "operates beneath every data and AI interaction in your workspaces automatically", enforcing access control when you query a table or call a model, tracking lineage as assets are used, and logging activity for auditing.

It has been on by default for a long time. Any Databricks workspace created after 8 November 2023 on AWS, or 9 November 2023 on Azure, has Unity Catalog enabled automatically. Everything is modeled as a securable object in a three level namespace of catalog, schema and object, and that covers tables, views, volumes, functions, models and services.

So the honest starting position is the same one we take on Snowflake Horizon Catalog: a single-platform team should turn the native thing on first. You are already paying for it, and no third party is going to enforce a row filter better than the engine that owns the data. The evaluation question is not "Unity Catalog or a vendor". It is whether your data actually stays inside Databricks, and whether you can live with the documented gaps below.

What Unity Catalog costs: the platform tier uplift nobody prices

Search for Unity Catalog pricing and you will find a dozen pages telling you it is free. That is true of the SKU and misleading about the bill, for two reasons.

First, the tier. Databricks governance capabilities sit in the Premium tier and above, and the tier is not free. Databricks has since discontinued the Standard tier entirely for new customers on AWS and Google Cloud, and its own pricing FAQ states that any existing customer remaining on Standard on AWS and Google Cloud "will be automatically upgraded to the premium tier on Oct 1, 2025". On Azure, where both tiers are still sold and where Microsoft publishes list prices through a public API, you can see exactly what that upgrade is worth.

Azure Databricks list prices for East US, Consumption, pulled from the public Azure retail price API on 23 August 2026. Databricks publishes the equivalent AWS and Google Cloud rates on its own pricing pages. Committed-use discounts change the rate; they do not change the ratio between tiers. Check your own contract before budgeting.

The number worth sitting with is the first row. A batch estate that runs mostly on Jobs Compute pays exactly twice as much per DBU on Premium as on Standard at list. That is the real price of the governance layer, and it is invisible if you only read the sentence that says Unity Catalog has no separate charge.

Second, the monitoring meter. Data quality monitoring in Unity Catalog is serverless and billed in DBUs, not bundled. Databricks documents that for results created from February 2026 the usage shows up in system.billing.usage under a billing_origin_product of DATA_QUALITY_MONITORING, split between anomaly detection enabled at schema level and data profiling enabled at table level. The documentation tells you how to query what you already spent. It does not give you a way to forecast it or cap it, so the practical control is how many tables you profile and how often. If you are weighing that meter against a fixed-price product, our data quality tools comparison covers what the standalone vendors charge.

Where Unity Catalog lineage stops, according to the Databricks documentation

Unity Catalog lineage is genuinely good and better than most people assume. It is automatic, it is column level, it spans notebooks, jobs, dashboards, SQL queries, Lakeflow pipelines and models, and you do not configure anything to get it. The limits are all documented rather than hidden, and they are the reason teams end up buying something alongside it.

Renaming breaks the chain. This is the one that catches people, and it appears in a plain list in the Databricks lineage documentation: lineage is not preserved after renaming catalogs, schemas, tables, views, or columns. A refactor that renames a column is exactly the moment you most want lineage, and it is the moment the graph forgets. If you are documenting a migration for an auditor, that matters.

Some workloads never emit a job link. Jobs submitted through the Jobs API runs submit request or the spark submit task type still produce table and column lineage, but they lose the link back to the job run that caused it. You can see that the data moved and not what moved it.

Column lineage has two blind spots. Databricks documents that column lineage cannot be captured when the source or the target is referenced as a path rather than by table name, and when a user defined function obscures the mapping from source columns to target columns. Both are common in real Spark code. The lineage system tables carry a further caveat worth quoting: both tables "represent a subset of all read/write events, as it is not always possible to capture lineage", and records are only emitted when lineage can be inferred.

Several object types are excluded outright: Resilient Distributed Datasets, global temporary views, tables under system.information_schema, and Spark SQL dataset checkpointing operations. Lakeflow pipelines that use PRIVATE tables get incomplete coverage.

Runtime floors apply. Lineage tracking of streaming between Delta tables requires Databricks Runtime 11.3 LTS or above, and column lineage for Lakeflow pipeline workloads requires 13.3 LTS or above. If part of your estate is on older runtimes, part of your lineage is simply missing.

One documented behavior runs the other way and is worth knowing because it surprises people during incident review: lineage events persist even if the transaction is rolled back. A failed write can still leave an edge in the graph. That is arguably correct, since something did read and attempt to write, but it means the lineage graph is a record of attempted access rather than a record of committed state. If you are using lineage as evidence, say which of those two you mean. Our column-level lineage and impact analysis pages cover how we handle the same problem.

The two retention windows, and which one an auditor cares about

Databricks keeps lineage in two places with two different retention rules, and comparison pages routinely quote one and imply the other.

• The lineage system tables (system.access.table_lineage and system.access.column_lineage) "retain a rolling 1-year window of data. Events older than one year are removed on a rolling basis." This is the queryable, joinable, scriptable copy, and it is the one you would build a report or a control on.
• Catalog Explorer and the lineage REST API preserve lineage indefinitely, from 1 September 2024 onward. Nothing before that date exists at all.

So the accurate statement is not "Databricks keeps one year of lineage". It is that the copy you can query in SQL keeps one year, the copy you can browse in the UI goes back to September 2024, and there is a hard floor before which no lineage exists regardless of interface. If your control requires evidence of how a regulatory number was derived three years ago, neither window reaches it, and the answer is to capture and store lineage snapshots yourself. That is the same conclusion we reached about the one-year window in Snowflake Horizon Catalog, and it is not a coincidence: warehouse-native lineage is built for operations, not for archives.

There is a second wrinkle for the REST API. It answers with immediate upstream and downstream neighbors, one hop at a time. Walking a full multi-hop chain means calling it repeatedly and stitching the graph yourself, which is fine for a script and awkward for a control that has to run every quarter.

The Unity Catalog quotas worth checking before a rollout

Unity Catalog enforces resource quotas on securable objects. Most are generous, a few are fixed and cannot be raised, and two of them shape whether you can push lineage from outside Databricks into it at all.

Quotas from the Databricks resource limits documentation, checked 23 August 2026. "Fixed" means Databricks documents the limit as not adjustable.

The last two rows are the interesting ones. Databricks supports pushing lineage for systems it does not run, and caps it at 100,000 external lineage relationships and 10,000 external metadata objects per metastore, both fixed. For a warehouse-shaped estate that is plenty. For a company trying to represent an entire stack of BI dashboards, reverse ETL destinations and operational services inside Unity Catalog, 10,000 external objects is a real ceiling, and it arrives sooner than the million-table number suggests. Databricks itself notes that pushed lineage does not match native lineage for depth or automation, and that editing lineage metadata and syncing it back to external systems are not supported.

When Unity Catalog is enough, and when it is not

Use Unity Catalog and stop there if your analytics estate is genuinely Databricks-shaped: sources land in the lakehouse, transformation happens in Lakeflow or notebooks, consumption happens in Databricks SQL or a dashboard Databricks can see, your runtimes are current, and your retention requirement is operational rather than archival. In that case a third party tool adds a bill and a login and very little signal.

Look at something alongside it when any of these are true. Your lineage has to cross into dbt Cloud, Airflow, Fivetran, Looker, Tableau or Power BI and you want it captured rather than pushed. You need lineage evidence that outlives a rolling year in SQL or predates September 2024. You rename objects during refactors and cannot afford the graph to forget. You want impact analysis on a pull request, before the change ships, rather than an incident review afterward. Or you run more than one warehouse, which is common enough that our data lineage tools comparison exists mostly to answer it. If Microsoft Purview is also on your shortlist, we compare the two catalogs meter by meter in Unity Catalog vs Purview.

Datatrail connects to Databricks read-only, parses query history and dbt artifacts to build column-level lineage, keeps the history on your retention terms rather than a rolling window, and follows the same columns into the orchestrator and the BI layer. It does not replace Unity Catalog, and we would not suggest turning access control or masking over to a third party. It sits next to it and covers the part of the graph that stops at the workspace boundary. For a broader look at what else is in this category, see our data observability tools roundup.