Apache Polaris and Unity Catalog Assess

Overview

Apache Polaris and Databricks Unity Catalog represent converging open and commercial catalog layers for multi-engine table governance (Polaris, Unity Catalog). Polaris left the Apache Incubator in February 2026 (Polaris graduation); Unity Catalog exists both as the managed Databricks service and as an Apache-2.0 open-source project in LF AI & Data (Unity Catalog OSS).

Assess which catalog will anchor your lakehouse IAM model before duplicating policies across engines.

Adoption Signals

  • Polaris graduated to a top-level Apache project with 27 +1 votes and no objections, six releases during incubation, over 2,800 merged pull requests and PMC members from Dremio, Snowflake, Google, Microsoft, Confluent and LanceDB (Dremio graduation post).
  • Release cadence is steady after graduation: 1.4.0 in April 2026 added multi-tenancy and storage-scoped credentials (Polaris 1.4 release), and 1.8.0 shipped on 28 September 2026 (Polaris releases).
  • Commercial services run on Polaris: Snowflake Open Catalog is a generally available managed Polaris service (Snowflake Open Catalog), and SAP plans a universal open catalog built on Polaris for SAP Business Data Cloud after acquiring Dremio, announced in May and completed on 6 July 2026 (SAP to acquire Dremio, SAP completes Dremio acquisition).
  • Databricks reports more than 14,000 organizations governing data and AI on Unity Catalog and announced Iceberg v3 and managed Iceberg as generally available at Data + AI Summit 2026 (What's new in Unity Catalog).
  • Unity Catalog exposes all its Iceberg tables through the Iceberg REST Catalog API, so external engines can read and write managed Iceberg tables (Iceberg in Databricks).
  • Open-source Unity Catalog 0.6.0 (August 2026) added metric views, SQL views and Spark 4.2 support on top of the UC Delta API introduced in 0.5.0 (Unity Catalog releases).

Risks

  • Asymmetric format support. Polaris generic tables for Delta and other formats are beta, with no commit coordination and no credential vending (Polaris generic tables); Databricks treats foreign Iceberg tables as read-only and does not support branching or tagging (Iceberg in Databricks). Running both catalogs does not give every engine full write access to every table.
  • Open versus managed Unity Catalog. The open-source project is an LF AI & Data sandbox project at version 0.6 (Unity Catalog OSS, Unity Catalog releases); features such as ABAC policies, domains and managed disaster recovery are announced for the Databricks service (What's new in Unity Catalog), so an OSS deployment is not a like-for-like substitute.
  • Policy duplication and drift. The Iceberg REST specification standardises table operations, not a shared permission model. Grants in Polaris RBAC and in Unity Catalog have to be kept consistent by your own tooling if both catalogs hold the same data.
  • Vendor-controlled managed layers. Managed Polaris comes from Snowflake or from Dremio, now part of SAP (SAP completes Dremio acquisition); Databricks' Iceberg support requires a Unity Catalog workspace, which a competing vendor describes as a lock-in point (Onehouse analysis).
  • Upgrade cadence. Polaris shipped five minor releases between April and September 2026 and removed deprecated APIs along the way, for example convenience overloads of IcebergCatalogHandler in 1.8.0 (Polaris releases); self-hosting means tracking these upgrades.

Pros & Cons

Advantages

  • Both catalogs implement the Iceberg REST Catalog API, so Spark, Flink, Trino, Snowflake, Dremio and Databricks can share one set of tables and one access-control model instead of per-engine metastores.
  • Apache Polaris graduated to an Apache top-level project in February 2026 with a multi-vendor PMC (Dremio, Snowflake, Google, Microsoft, Confluent, LanceDB), which lowers single-vendor dependency for the open option.
  • Unity Catalog is the governance layer of an established platform: Databricks reports more than 14,000 organizations on it and made managed Iceberg and Iceberg v3 generally available in June 2026.

Disadvantages

  • Neither catalog governs the other's native formats equally: Polaris generic tables (Delta, CSV) are still beta without commit coordination or credential vending, and Databricks treats foreign Iceberg tables as read-only.
  • The open-source Unity Catalog (LF AI & Data sandbox, v0.6 in August 2026) is pre-1.0 and lacks much of what Databricks ships in its managed Unity Catalog, so "open" and "managed" behave differently.
  • Managed offerings are tied to vendor roadmaps: Snowflake Open Catalog and Dremio's catalog (SAP completed its acquisition of Dremio in July 2026) wrap Polaris, and Databricks' Iceberg features require a Unity Catalog workspace.

Recommendation

Assess this pair as a platform decision, not a tool comparison. The question is which catalog holds the authoritative grants for your lakehouse tables. If Databricks is the main compute platform, Unity Catalog is already the governance layer and the assessment is about how far external engines can use its Iceberg REST endpoint. If the estate is Iceberg-first and spans Snowflake, Trino, Flink or Dremio, Polaris (self-hosted or via Snowflake Open Catalog) is the vendor-neutral candidate.

Run the assessment on a small set of real tables with at least two engines writing, and test the cases that break: cross-catalog writes, credential vending per engine, grant changes and their propagation, and table maintenance. Avoid a design in which both catalogs have write authority over the same tables. For regulated workloads, document where audit logs for grants and data access live in each option before any production data moves. Reassess when Polaris generic tables leave beta or open-source Unity Catalog reaches 1.0.

Sources