Open by Design: Snowflake’s Commitment to Iceberg and Interoperability

At Snowflake, we believe that open data formats only deliver on their promise when they are paired with open interoperability. Formats like Apache Iceberg were created to enable choice, portability and collaboration across engines, clouds and vendors. Those principles matter deeply to us.

That is why Snowflake supports full bidirectional interoperability through the Iceberg REST Catalog. Whether Snowflake is acting as a consumer of Iceberg tables managed elsewhere or as a source for downstream systems, we believe customers, not platforms, should decide how and where their data is used.

What bidirectional interoperability means in practice

The Iceberg REST Catalog defines a neutral, vendor-independent control plane for Iceberg metadata. When implemented openly, it allows systems to interoperate without requiring proprietary integrations, tight coupling or special case logic. Snowflake supports this model in both directions. Snowflake can federate outbound to any Iceberg REST Catalog-compliant endpoint. Snowflake can also expose its own Iceberg tables through an Iceberg REST Catalog endpoint so downstream systems can consume them using standard Iceberg clients. 

This is not a one-way door. It is a deliberate choice to support symmetry and openness — because ultimately, embracing open interoperability reduces friction and saves time. Customers don’t have to worry about formats used or catalog incompatibilities. We’re supporting an open ecosystem that we believe is the new standard for interoperability. 

Snowflake as a consumer: Federating outbound

When Snowflake federates outbound, it acts as a standards-compliant Iceberg platform. Customers can point Snowflake at an Iceberg REST Catalog endpoint operated by another system and immediately begin querying or writing Iceberg tables. By using vended credentials by the remote catalog, the process avoids proprietary adapters or vendor lock-in.

This model allows Snowflake to participate in open Iceberg ecosystems without assuming ownership or control of the catalog itself. After all, putting restrictions on federating to outside sources largely defeats the purpose of open interoperability. It undermines the spirit of Iceberg altogether. 

Snowflake as a source: Enabling downstream federation

When it comes to Iceberg data, Snowflake does not see openness as a competitive risk. We view it as a baseline requirement for interoperability. This means Snowflake natively supports operating as a source for downstream federation. 

When Snowflake exposes Iceberg tables through the Iceberg REST Catalog, downstream engines can discover tables using standard Iceberg metadata APIs; read and write data using Iceberg semantics; securely use credentials vended by Snowflake Horizon Catalog; and operate independently of Snowflake’s execution engine.

Supporting outbound federation using the Iceberg REST Catalog gives customers the optionality to bring Snowflake data into their platform of choice. 

A clear view of the current landscape

Here is a clear summary of which products can federate outbound to an arbitrary third-party Iceberg REST Catalog endpoint.

Our position on open formats

Our view is simple. Open formats should be implemented openly. Interoperability should be bidirectional. Customers should not need to ask permission to move or share their data. We will continue to invest in Iceberg, the Iceberg REST Catalog, Apache Polaris and open standards broadly. We also encourage others in the ecosystem to treat open formats with the same level of openness — not only as an ingestion mechanism, but as a foundation for true interoperability. 

Open data works best when everyone plays by open rules.

Access Snowflake Iceberg tables via external engines and catalogs: Documentation

Access remote/external Iceberg tables via Snowflake: Documentation