The Open Interoperability Standard: Why Bidirectional Iceberg REST Matters

Details

The data lakehouse standard war between Snowflake and Databricks has opened a new front: Apache Iceberg REST Catalog interoperability. Snowflake's Horizon team argues that true open interoperability requires bidirectional federation — both allowing external engines to access your Iceberg tables (inbound) and the ability to read and write Iceberg tables managed by other catalogs (outbound). Snowflake's Horizon catalog implements the full Iceberg REST Catalog protocol in both directions. Databricks Unity Catalog, per Snowflake's post, only delivers inbound — external engines can connect to Unity Catalog's REST endpoints, but Databricks itself accesses external catalogs through a proprietary path: the Snowflake Catalog SDK via JDBC to fetch metadata, then direct storage access via preconfigured IAM credentials. More critically, external Iceberg tables in Databricks are explicitly read-only; writes to non-Unity-Catalog Iceberg tables are not supported. The practical implication for enterprise architects: organizations that standardize on Databricks cannot write to Iceberg tables managed by other catalogs such as Snowflake, AWS Glue, or Apache Polaris — a meaningful constraint for multi-cloud or multi-vendor data architectures as Apache Iceberg adoption grows. Important caveat: this is a Snowflake marketing post and Databricks has not provided a rebuttal here. The claims reference documentation that may change — verify Unity Catalog's current capabilities independently before making architectural decisions.