Unity Catalog Interoperability

What external engines can do with Unity Catalog managed Iceberg tables today, in the vendors' own words. Including the engine that wrote the scorecard.

On July 15, 2026, Snowflake published a comparison of Snowflake Horizon Catalog and Databricks Unity Catalog. Its conclusion: with Unity Catalog, "you are effectively required to migrate your entire data estate to Unity Catalog." Its scorecard grades Unity Catalog "Inbound only" on credential vending and "read-only" on external catalog tables.

Snowflake also publishes a tutorial. It walks a Snowflake user through connecting to Unity Catalog with credentials Unity Catalog vends, inserting rows into a table Unity Catalog manages, and creating a new table inside Unity Catalog, all from Snowflake. The article and the tutorial describe the same two products. One of them is an argument. The other is running SQL.

Interoperability, defined before it is scored

Snowflake's article opens by defining the term on its own terms: "True interoperability requires both inbound and outbound federation via open community driven standards." Then it grades.

Here is the definition that matters to the team that owns the data. Interoperability means an engine you did not buy from the catalog vendor can read a table, write to it, and create new ones, using credentials the catalog issues and can revoke, over a protocol no single vendor controls. In practice that is the Apache Iceberg REST Catalog protocol with credential vending. It is also the only test that bears on the migration claim. A catalog that any engine can read, write, and create in is not a catalog you are trapped inside. The question is which catalog passes that test today, at GA, for the tables it manages.

Unity Catalog vs. Snowflake Horizon Catalog, by documented status

Snowflake's tutorial does what Snowflake's article says cannot be done

Snowflake's documentation, "Set up bidirectional access to Iceberg tables in Unity Catalog," runs the following from a Snowflake session. The catalog integration points at Unity Catalog's Iceberg REST endpoint and asks Unity Catalog to vend the credentials:

CREATE CATALOG INTEGRATION ...  
  CATALOG\_URI \= '\<databricks\_workspace\_url\>/api/2.1/unity-catalog/iceberg-rest'  
  ...  
  ACCESS\_DELEGATION\_MODE \= VENDED\_CREDENTIALS  
  ...

CREATE DATABASE unity\_linked\_db  
  LINKED\_CATALOG \= (  
    CATALOG \= 'my\_unity\_catalog\_int\_vended\_creds'  
    BLOCKED\_NAMESPACES \= ('information\_schema')  
  );

INSERT INTO customers.customer\_accounts (...) VALUES (6, 1006, 'ACTIVE', ...);

CREATE ICEBERG TABLE table\_created\_from\_snowflake (id INT, name STRING, created\_date DATE);

Three things happen in that sequence. Snowflake authenticates with credentials Unity Catalog vended. Snowflake writes rows into a table Unity Catalog manages. Snowflake creates a new table inside Unity Catalog. Nothing migrated. The data stayed in Unity Catalog, governed by Unity Catalog, and Snowflake came to it. Snowflake's catalog-integration documentation lists Unity Catalog as a supported remote catalog on AWS, Azure, and Google Cloud.

Set that beside the scorecard's Row 2 cell: "Lakehouse Federation is read-only. No INSERT, UPDATE, DELETE or MERGE on external catalog tables." The cell is about Databricks writing outward. The tutorial is about Snowflake writing inward. Both are true. Only one of them supports a claim about migration, and it is not the one Snowflake put on the table.

What "single pane of glass" is scoped to

The article's strongest sentence about itself: "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."

The load-bearing words are the last three. For tables Snowflake manages, that is accurate, and Databricks makes the equivalent statement about tables Unity Catalog manages. For tables managed anywhere else, the Horizon path shipped as a Preview on August 18, 2026, a month after the article ran. In that Preview, "Credential vending for externally managed tables is disabled by default," and Snowflake's own page warns that enabling it can extend a credential's scope to "the files of any other table stored under the same prefix, including Snowflake-managed Iceberg tables." The article's footer says the rest: "This post references features that are in Public Preview and subject to change. Preview features may not be suitable for production use."

Snowflake's scorecard grades Databricks on Databricks' GA surface, then grades itself on Preview features. That is measuring two different things.

"You can still use Databricks but without Unity Catalog"

That is a section heading in the article. Read it with the tutorial in view. The one component Snowflake advises leaving behind is the one Snowflake's own documentation connects to, writes into, and creates tables inside. The advice is not interoperability guidance. It is a request to drop your governance layer so that another vendor can take its place. Interoperability that requires abandoning your catalog is migration with a friendlier name.

What Databricks does not do today

One gap, stated plainly: Snowflake's scorecard is correct that Databricks lacks a generic outbound Iceberg REST client for writing directly to third-party catalogs. Databricks reaches external catalogs (including Snowflake Horizon Catalog) through Lakehouse Federation connectors, reading their storage via customer-configured external locations. As Databricks' own documentation notes: "External federated Hive metastore and all foreign tables accessed through Lakehouse Federation are read-only." Snowflake can write into Unity Catalog today; Databricks compute cannot write into Horizon today.

But that path is outbound: pushing writes to a catalog Databricks does not manage. Snowflake's broader marketing claim (that Unity Catalog forces you to "migrate your entire data estate") is about the opposite direction. If your data lives in Unity Catalog, does any other engine have to leave it behind or migrate it out? Snowflake's own SQL integration proves the answer is no. It is the one capability the scorecard never tests, yet it is the only one that determines whether the migration claim is true. It is not.

The fine print the article leaves out

Snowflake's bidirectional path is real and it has costs, all from Snowflake's documentation. Writing to external catalogs from Snowflake: "Snowflake supports autocommit transactions only." Creating tables in nested namespaces "isn't currently supported," and writing to them "isn't currently supported." "Snowflake doesn't sync remote catalog access control for users or roles." And when external engines read Snowflake-managed tables through Horizon IRC, "The API requests are billed as 0.5 credit per million calls and charged as Cloud Services," with billing scheduled to begin in the second half of 2026.

Databricks has fine print too, and it is in the table above: multi-statement transactions that write to managed Iceberg tables are Private Preview, and foreign tables are read-only. None of that changes the claim Snowflake actually made. Its article pretends the conditions only run one way.

The test that matters

Ask one question of any catalog: can an engine I did not buy from this vendor read, write, and create tables here today, at GA, with credentials this catalog issues? For Unity Catalog managed Iceberg tables, the answer is yes in Databricks' documentation and yes in Snowflake's. The engine that proved it is Snowflake.

Sources

[1] Snowflake, "Open Interoperability: Delivering Customer Choice," July 15, 2026. https://www.snowflake.com/en/blog/bidirectional-interoperability-snowflake-horizon-databricks/

[2] Snowflake, tutorial "Set up bidirectional access to Iceberg tables in Unity Catalog." https://docs.snowflake.com/en/user-guide/tutorials/tables-iceberg-set-up-bidirectional-access-to-unity-catalog

[3] Snowflake, "Configure a catalog integration for Databricks Unity Catalog." https://docs.snowflake.com/en/user-guide/tables-iceberg-configure-catalog-integration-rest-unity

[4] Databricks release notes, May 21, 2026. https://docs.databricks.com/aws/en/release-notes/product/2026/may

[5] Databricks, "Managed tables." https://docs.databricks.com/aws/en/tables/managed

[6] Databricks, "Unity Catalog credential vending." https://docs.databricks.com/aws/en/external-access/credential-vending

[7] Databricks blog, "Expanded Interoperability with Unity Catalog Open APIs," May 14, 2026. https://www.databricks.com/blog/expanded-interoperability-unity-catalog-open-apis

[8] Databricks, "Work with foreign tables." https://docs.databricks.com/aws/en/tables/foreign

[9] Databricks, "Snowflake Horizon Catalog federation." https://docs.databricks.com/aws/en/query-federation/snowflake-catalog-federation

[10] Snowflake, "Write to externally managed Iceberg tables." https://docs.snowflake.com/en/user-guide/tables-iceberg-externally-managed-writes

[11] Snowflake release note, March 31, 2026. https://docs.snowflake.com/en/release-notes/2026/other/2026-03-31-ctas-unity-catalog-external-volumes

[12] Snowflake, "Access externally managed Iceberg tables through Horizon IRC." https://docs.snowflake.com/en/user-guide/externally-managed-iceberg-tables-access-horizon-irc

[13] Snowflake, "Access Snowflake-managed Iceberg tables using an external query engine." https://docs.snowflake.com/en/user-guide/tables-iceberg-access-using-external-query-engine-snowflake-horizon

[14] Snowflake, "Catalog-linked databases." https://docs.snowflake.com/en/user-guide/tables-iceberg-catalog-linked-database