Open table formats moved the data itself onto cheap object storage any engine can read. What is left to fight over is the catalog: the component that decides who sees which table and how engines find it. Three names dominate that conversation in 2026, Apache Polaris, Databricks Unity Catalog, and Microsoft Purview, and they are not the same kind of product.
Why is the catalog now the governance layer of the lakehouse?
Because in a lakehouse the catalog is the last centralized chokepoint: it maps table names to metadata, authorizes every read and write, vends short-lived storage credentials, and records the audit trail. Whoever operates the catalog effectively controls the lakehouse, even when the Parquet files sit in buckets you own.
Two shifts made this true:
- ▸The Iceberg REST catalog protocol became the de facto interoperability standard; Spark, Trino, Flink, DuckDB, Snowflake, and ClickHouse can all speak it, so the catalog is the one integration point every engine shares
- ▸Credential vending replaced bucket-wide IAM: engines receive short-lived, table-scoped storage credentials from the catalog per request, which centralizes authorization and produces a per-table audit trail
That combination turns catalog selection into an architecture decision with a decade of consequences, not a tooling preference. Making the resulting rules livable for engineers is its own craft; see Data Governance Engineers Will Actually Use.
What is Apache Polaris, and when is it the right choice?
Apache Polaris (incubating) is an open-source metadata catalog implementing the Iceberg REST protocol, contributed by Snowflake to the Apache Software Foundation in 2024. It provides engine-neutral table governance with role-based access control, OAuth2 authentication, credential vending, and multiple catalogs per instance, and you can self-host it entirely, typically as a container backed by PostgreSQL.
Polaris fits when:
- ▸Your estate is Iceberg-first and several engines need first-class access
- ▸Self-hosting or EU residency is a requirement, not a preference
- ▸You want exit cost near zero: the protocol is open and your metadata sits in your own database
- ▸You accept that lineage, classification, and data-loss prevention live elsewhere; Polaris is a table catalog, not a governance suite
Snowflake operates a managed flavor as Open Catalog if you want the protocol without the ops. Neighbors in the same lane worth shortlisting: Lakekeeper (a lean Rust implementation), Apache Gravitino (incubating, federates metadata beyond Iceberg), and Project Nessie (git-style branching for tables). Check each project's current status and release cadence before committing; incubating projects move fast in both directions.
What does Unity Catalog govern, and which parts exist only inside Databricks?
Unity Catalog is the governance layer of the Databricks platform, covering tables, files, volumes, functions, and ML models with row- and column-level controls, lineage, and audit. An open-source core was donated to LF AI and Data in 2024, but the capabilities buyers shortlist it for, such as automated lineage, attribute-based access control, and the mature UI, remain paid-platform features.
The nuances that decide real evaluations:
- ▸Iceberg interop has grown steadily: UniForm exposes Delta tables through Iceberg metadata, managed Iceberg tables exist, and Unity exposes an Iceberg REST endpoint external engines can use; the exact read and write scope changes often enough that you should verify it against current Databricks documentation
- ▸Inside Databricks it is excellent and effectively the default; fighting it there is wasted effort
- ▸Outside Databricks the open-source build is thinner than the branding suggests; evaluate it feature by feature against Polaris or Lakekeeper before self-hosting it
- ▸Its gravity is real: the catalog is one of the strongest platform lock-in mechanisms Databricks has, precisely because it is good
Where does Microsoft Purview fit, and what is it not?
Purview is an enterprise data-governance and compliance suite: discovery and scanning across hundreds of source types, classification, sensitivity labels, data-loss prevention, and a business glossary. It is not an operational table catalog; query engines do not resolve table metadata or fetch storage credentials through Purview at read time. It sits a layer above catalogs like Unity or Polaris.
Where it earns its keep:
- ▸Estates already deep in Microsoft 365, Azure, and Fabric, where its scanners and sensitivity labels reach places lakehouse catalogs never will
- ▸Compliance teams that must answer where personal data lives across the whole company, not just the lakehouse
- ▸Regulated audits that want one inventory spanning SQL Server, SaaS applications, file shares, and the lake
It is SaaS-only and Microsoft-operated; residency comes from region selection and Microsoft's EU Data Boundary commitments, which are contractual arrangements you should verify against Microsoft's primary documentation. Self-hostable alternatives in this metadata-governance lane are OpenMetadata and DataHub.
How do the three compare side by side?
The short version: Polaris is an operational Iceberg catalog you can own; Unity is a platform catalog that is excellent inside Databricks and thinner outside it; Purview is a compliance and discovery layer that governs metadata about your data rather than access to your tables. The axes below decide real projects.
| Axis | Apache Polaris | Unity Catalog | Microsoft Purview | | --- | --- | --- | --- | | Product type | Operational Iceberg REST catalog | Platform catalog and governance | Compliance and discovery suite | | Table formats | Iceberg | Delta first, growing Iceberg interop | Not applicable (harvests metadata) | | Query-time authorization | Yes, with credential vending | Yes, in Databricks and via REST | No | | Lineage and classification | No | Yes, on the paid platform | Yes, estate-wide | | Fully self-hostable | Yes | Partially (open-source core only) | No | | Sovereignty ceiling | Your infrastructure, your keys | Contractual on Databricks SaaS | Contractual, Microsoft-operated | | Cost model | Infrastructure plus your ops | Bundled into Databricks spend | Capacity-based SaaS pricing | | Exit cost | Low; open protocol and metadata | Medium; permissions and lineage stay | Low for data, high for process |
Feature edges on this table move quarterly; treat it as a map of categories and verify specifics against current documentation before deciding.
Which selection criteria should actually drive the decision?
Five questions settle most catalog decisions: where must query-time authorization live; how many engines must be first-class in three years; does regulation or internal policy require self-hosting; how much governance depth, meaning classification, lineage, and DLP, do you need now; and what would leaving cost. Answer these before opening any feature matrix.
Our shorthand after running these evaluations:
- ▸Choose Polaris or Lakekeeper for an Iceberg-first, multi-engine estate with residency requirements, accepting that lineage and discovery arrive as separate tools
- ▸Choose Unity Catalog when Databricks is your center of gravity and you want governance that simply works there
- ▸Add Purview or OpenMetadata on top when a compliance function needs estate-wide inventory beyond the lakehouse
One forward-looking criterion: if AI agents will query your lakehouse, catalog metadata becomes their map of your business, and its quality caps their accuracy. That is the argument made in Why Text-to-SQL Alone Fails in Production: The 2026 Case for a Semantic Layer in Front of Your Agent and RAG and Data Engineering in 2026: Your AI Is Only as Good as Your Data.
Can you combine catalogs without creating a governance mess?
Yes, and most 2026 estates do: one operational catalog acts as the single write path and source of truth for table access, while a compliance catalog harvests its metadata read-only. The mess begins when two systems both claim authority over the same tables and their permissions, so pick exactly one commit path per table.
Patterns that hold up:
- ▸Polaris operational, Purview or OpenMetadata harvesting: engines authorize through Polaris; the governance suite scans, classifies, and reports without touching access control
- ▸Unity operational inside Databricks, Purview scanning it: the common shape in Azure-centric estates
- ▸Federation as a bridge, not a destination: Polaris external catalogs and Unity federation of Hive Metastore or Glue exist for migrations; a permanent bidirectional ACL sync is an outage and an audit finding waiting to happen
Which catalog can you actually run sovereign in the EU?
Only the open-source operational catalogs, meaning Apache Polaris, Lakekeeper, Gravitino, or Nessie, run with no foreign control plane: your Kubernetes, your PostgreSQL, your keys, your audit logs. Unity Catalog open source self-hosts with a reduced feature set. Databricks-managed Unity and Purview are provider-operated SaaS: residency by region selection and contract, not by architecture.
In practice the decision splits on how hard your sovereignty requirement is. Where it is a legal or contractual obligation, a self-hosted Iceberg REST catalog on EU infrastructure is the defensible answer; where it is a preference, managed offerings in EU regions may pass review. That analysis, covering who operates the control plane, where support staff sit, and what an exit costs, is the same one laid out in Sovereign Cloud in 2026: Data Residency, Exit Strategies, and Pragmatic Multi-Cloud and EU Data Residency: Why Where Your Data Lives Matters in 2026. Sovereignty frameworks such as the EU cloud certification schemes are still moving; verify current status against primary EU sources before writing them into contracts.
How TuniCyberLabs helps
We run catalog selection as an engineering exercise, not a bake-off of vendor decks: a short assessment of your engines, formats, residency constraints, and exit posture, followed by a hardened deployment. That means self-hosted Polaris or Lakekeeper on EU infrastructure, Unity Catalog done right inside Databricks, or Purview integrated above either, plus migration off Hive Metastore or Glue. If a catalog decision is blocking your lakehouse roadmap, talk to our team.