The Open Interoperability Standard: Why Bidirectional Iceberg REST Matters

The Open Interoperability Standard: Why Bidirectional Iceberg REST Matters

Skip to content

Blog / Product and Technology / Open Interoperability: Delivering Customer Choice

JUL 15, 2026 / 8 min read Product and Technology Open Interoperability: Delivering Customer Choice

Carlos Nai +1

Open Interoperability: Delivering Customer Choice

While intuitively apparent to the readers of this blog, let's define open interoperability first. Open interoperability is the ability to architect your organizations' data platform to securely access governed data through open, published, standards-based interfaces , reducing proprietary lock-in and enabling broader ecosystem compatibility.

Open interoperability changes the relationship organizations have with their data. It provides them with agency over their data, the ability to freely choose the best engine and tool for each workload without onerous migrations or data movement. This definition is core to how Snowflake delivers first-class experiences for Apache Iceberg™ and Apache Polaris™. The result allows customers to platform their Iceberg tables on Snowflake or elsewhere, while being able to fully read and write to these tables without forcing migration to our catalog.

Databricks Unity Catalog also claims to be interoperable, yet upon close examination, we see that it fails to meet the most basic promises of open interoperability: the ability to read or write to any Iceberg table and to do so using open security mechanisms that avoid lock-in to any one tool.

Read and write to any Iceberg table

Choosing a catalog for your tables is the most critical decision in your architecture. It determines what operations you can do on these or other tables, expanding or limiting your choice. This is where true interoperability comes in. True interoperability requires both inbound and outbound federation via open community driven standards. Inbound federation means engines external to your catalog can read and write to your Iceberg tables, and outbound federation means that you can read or write to Iceberg tables managed by a different catalog.

Unity Catalog fails the interoperability test

As of this writing, Unity Catalog only supports full interoperability in one direction, inbound. For inbound access, external engines are able to connect to Unity Catalog's Iceberg REST Catalog end points to get access to the table. For outbound access, the picture is fundamentally different. When accessing Iceberg tables from external catalogs like Snowflake Horizon, Databricks does not use the Iceberg REST Catalog APIs. Instead, it uses the Snowflake Catalog SDK which uses JDBC to fetch the metadata.json path, and then accesses the underlying storage directly using preconfigured IAM credentials ( docs ). What's more, this only works for read operations. Iceberg tables managed by external catalogs remain explicitly read-only; writes to external Iceberg tables are not supported ( docs ).

The impact to your ability to unlock agency over your data is undeniable. When you platform your workloads with Databricks and Unity Catalog, you are effectively required to to migrate your entire data estate to Unity Catalog, undermining the basic promise of interoperability and their own claim of Unity Catalog as the most "interoperable catalog on the market."

Snowflake's Horizon Catalog is fundamentally different. Built on the foundation of Apache Polaris, Snowflake Horizon Catalog provides an end-to-end implementation of the Iceberg REST Catalog protocol. Horizon is Snowflake's native governance layer where classification, access policies, lineage, quality and catalog management are applied consistently across Iceberg tables Snowflake manages or accesses without limiting read or write operations. What's more, data teams acting on data from Snowflake get a comprehensive picture of where sensitive data lives across their full estate, not a partial view bounded by platform or table type. This works because Horizon Catalog connects to external catalog like Unity Catalog via a feature called Catalog Linked Databases and directly calls the catalog's Iceberg REST Catalog endpoint to get access from the catalog for that specific query. There's no need to file a ticket with your platform team to try to negotiate for a new IAM role, a long-lived credential or to manage a new security mechanism.

Why open security matters to interoperability

The Iceberg REST Catalog defines how catalogs should securely talk to each other. The feature is called vended credentials. Vended credentials are short-lived tokens delegated by the source catalog for specific operations. It provides a mechanism for your catalog to be the source of truth for your tables and security posture. However, while it is defined in the Iceberg REST Catalog spec, there's no requirement that catalogs implement it. The alternative to vended credentials is broad based access via IAM roles and long-lived credentials like access keys. These approaches add complexity and potential risk to your security posture. First, they aren't scoped for the specific query or, in practice, a specific table. Second, policies must be duplicated in your source catalog and your IAM layer, doing away with the foundation for secure open interoperability as recommended in the Iceberg REST spec.

Snowflake Horizon Catalog fully implements vended credentials for both inbound and outbound federation, providing you a single pane of glass to manage your Iceberg tables and access policies for any engine that accesses your Snowflake-managed Iceberg tables. In practice, this means you can define access policies in Horizon Catalog and have them enforced in your preferred engine without additional work. While this has worked at the object level (catalog, namespaces and tables), the newly introduced Scan Plan API, in private preview, extends governance to fine-grained row and column level access controls for compatible engines. As of this writing, Unity Catalog does not respect your source catalog's access policies because it does not consume credentials vended by external catalogs.

Full breakdown: Most interoperable catalog? You decide

Capability Snowflake Horizon Databricks UC What the gap means for you

Iceberg REST Catalog credential vending implementation 🟢 Bidirectional: per-query vended credentials: Inbound and outbound federation 🟡 Inbound only. Outbound connections do not use IRC. 1 Unity Catalog introduces unnecessary security risks by...