What is the difference between Unity Catalog and AWS Glue Data Catalog?

Glue Data Catalog is a serverless metastore native to AWS, governed by IAM, with crawlers that register tables automatically. Unity Catalog is Databricks' governance layer, now open-sourced under the Linux Foundation, offering fine-grained access control, lineage, and audit across data and AI assets in one place. Glue is the lower-effort choice inside AWS; Unity is the deeper governance choice, priced in platform commitment.

Can Unity Catalog and AWS Glue work together?

Yes, and this is the detail that dissolves most of the either-or framing. Unity Catalog includes federation connectors for AWS Glue and Hive Metastore, so Glue catalogs can be mounted as foreign catalogs inside Unity. AWS added federation in the other direction too. Teams running Databricks on AWS commonly use Unity as the governing catalog with Glue federated in for legacy tables.

Does Unity Catalog support Apache Iceberg?

Yes. Unity Catalog implements the Iceberg REST Catalog API, including credential vending, so Iceberg clients like Spark, Flink, and Trino can read and write Unity-managed tables. Glue also exposes an Iceberg REST endpoint. Iceberg support is no longer a differentiator between them.

Is Unity Catalog open source?

The core is. Databricks open-sourced Unity Catalog under Apache 2.0 with a published OpenAPI spec, and it sits with the LF AI and Data Foundation. The open-source project and the managed Databricks service are not the same thing, though, and the governance depth people associate with Unity Catalog largely lives in the managed product.

Unity Catalog vs AWS Glue Data Catalog: How to Choose

Both of these hold the pointer that makes an Iceberg table a table, and the choice between them is not really a technical one. AWS Glue Data Catalog is the zero-effort default if your compute lives in AWS: serverless, IAM-governed, with crawlers that register tables for you. Unity Catalog buys materially deeper governance — fine-grained access control, lineage, and audit for data and AI assets in one place — and charges for it in platform commitment.

The decision rule is short: follow your compute. Deep-AWS shops take Glue. Databricks-centred estates take Unity. And the case that trips people up — running Databricks on AWS — usually ends with both, which is the part most comparisons miss entirely.

Unity Catalog vs Glue, side by side

	AWS Glue Data Catalog	Unity Catalog
Steward	AWS	Databricks; core is Apache 2.0 under LF AI & Data
Operating model	Serverless, no infrastructure	Managed in Databricks, or self-hosted OSS
Access control	IAM, plus Lake Formation for finer grain	Native fine-grained: catalog, schema, table, row, column
Lineage	Limited	First-class, captured automatically
Audit	CloudTrail	Unified across data and AI assets
Table registration	Crawlers discover and register automatically	Explicit registration
Iceberg REST API	Yes	Yes, with credential vending
Non-tabular assets	Tables	Tables, volumes, models, functions
Gravity	AWS	Databricks
Costs you	Cloud lock-in	Platform commitment
Fails by	Governance thinning out as the estate grows	Being overkill without the platform around it

What Glue is actually good at

Glue’s advantage is that it is already there. If your estate is Athena, EMR, Redshift Spectrum, and Glue ETL, the catalog requires no decision, no deployment, and no separate bill of its own. Crawlers infer schemas and register tables without anyone writing DDL, which for a lake accumulating files from many producers is a genuine reduction in toil.

The governance is IAM-shaped, which is a real strength if your organisation already runs on IAM and a real limit otherwise. Table- and column-level control means adding Lake Formation on top, and the lineage story is thin. That’s fine until the estate has enough consumers that “who can see this column, and who touched it last quarter” becomes a question someone has to answer in writing.

What Unity Catalog is actually good at

Unity’s advantage is that governance is one surface rather than four. Permissions, lineage, and audit cover tables, files, ML models, and functions together, which matters once AI assets stop being a side project. Where Glue tells you IAM allowed a call, Unity tells you which notebook read which column and what it fed.

It’s also less closed than its reputation suggests. Databricks open-sourced the core under Apache 2.0 with a published spec, and the project sits with the LF AI & Data Foundation. Worth being precise about what that means, though: the OSS project and the managed Databricks service are not the same thing, and most of the governance depth people buy Unity Catalog for lives in the managed product. Treat “it’s open source” as a statement about lock-in risk, not a statement about features.

Follow the compute. And notice that the middle branch is not a compromise, it is the usual answer.

The case nobody writes about: both

Running Databricks on AWS is not an edge case, and it does not force a choice. Unity Catalog ships federation connectors for Glue and Hive Metastore, so an existing Glue catalog mounts as a foreign catalog inside Unity, and AWS built federation in the other direction so Glue-side engines can reach Unity-governed tables.

The pattern that works: Unity as the governing catalog for anything new, Glue federated in for the legacy estate, migrating tables when there’s a reason rather than as a project. You get one governance surface without a big-bang migration, which matters because switching catalogs is the painful migration in a lakehouse — the data files never move, but every engine config, every access policy, and all accumulated audit history do.

Where the Iceberg story landed

This used to be a real differentiator and isn’t anymore. Unity Catalog implements the Iceberg REST Catalog API including credential vending, so Spark, Flink, Trino and anything else spec-faithful can read and write Unity-managed tables. Glue exposes an Iceberg endpoint too.

# Same Spark client, either catalog behind the URI.
spark.sql.extensions = org.apache.iceberg.spark.extensions.IcebergSparkSessionExtensions
spark.sql.catalog.lake = org.apache.iceberg.spark.SparkCatalog
spark.sql.catalog.lake.type = rest
spark.sql.catalog.lake.uri = https://<unity-or-glue-endpoint>/iceberg
spark.sql.catalog.lake.warehouse = my_warehouse
spark.sql.catalog.lake.rest.auth.type = oauth2
# token injected from a secret manager at submit time, never in a notebook cell
spark.sql.catalog.lake.token = ${ICEBERG_CATALOG_TOKEN}

That config is nearly identical either way, which is the point: the wire protocol converged, so the decision moved entirely to governance and gravity.

The decision rule

Compute is Athena / EMR / Redshift, governance needs are IAM-shaped?
   → Glue. Stop optimising; it is already there.

Compute is Databricks, and you need lineage, column-level control,
or one audit surface across data AND AI assets?
   → Unity Catalog.

Databricks on AWS with a legacy Glue estate?
   → Both. Unity governs, Glue federates in. This is the common case.

Deliberately avoiding both vendors' gravity?
   → Neither — that is the Polaris question, one layer over.

The trap worth naming: choosing Unity Catalog for governance you have no organisational capacity to operate. Fine-grained access control is only worth its setup cost if someone owns the policies and reviews them. Absent that, you’ve bought a more expensive metastore and inherited the same org-chart problem you started with. Glue plus genuine ownership beats Unity plus nobody, every time.