Choosing an Interoperable Catalog: Snowflake Horizon vs. Databricks Unity Catalog

In Part 1, we defined five decision principles for evaluating an enterprise Iceberg catalog: open standard compliance, governance universality, bidirectional interoperability, operational independence and feature completeness. This post applies those principles to Snowflake Horizon and Databricks Unity Catalog (UC) with the technical detail architects need.

Read/write capabilities across engines

The table below shows what each engine can do when Horizon owns the table. Read access is generally available (GA) as of February 2026. Write access via external engines is in public preview (March 2026). Snowflake reads and writes natively with no preview caveats.

On Databricks: A Databricks cluster running Apache Spark™ can connect to Horizon and read tables — this is a Spark capability, not a native Databricks catalog integration. Native Databricks catalog integration with Horizon has not been announced.

On Glue direction: The table above covers engines writing to Horizon. Snowflake writing to Glue-managed Iceberg tables is a separate, fully supported capability via catalog-linked databases (CLD) (GA October 2025).

Governance: Define once, enforce everywhere

Both Horizon and Unity Catalog expose Iceberg REST-compatible APIs and position themselves as multi-engine governance layers. The practical differences are in enforcement depth and ecosystem reach.

Horizon as catalog owner: Snowflake's role-based access control (RBAC), masking policies, row access policies and tag-based masking apply natively to Snowflake queries. For external engines, Spark policy enforcement is GA (via Snowflake Connector for Spark v3.1.6+, which routes governed queries through Snowflake). Other Iceberg REST-compatible engines (Apache Flink, DuckDB, PyIceberg) can access data through Horizon with credential vending; governance enforcement maturity varies by engine.

UC as catalog owner: UC's governance (access controls, column masking, row filters) applies natively to Databricks compute. External engines — including Snowflake via CLD — connect through UC's Iceberg REST endpoint with catalog-vended credentials. However, Snowflake does not sync UC's access control for users or roles.

Instead, Snowflake-native governance (masking policies, row access policies, tags) can be independently applied to UC-managed tables accessed through CLD. Certain other Snowflake platform capabilities (replication, cloning) are unavailable on catalog-linked tables.

The bottom line: Both catalogs expose REST APIs, support credential vending and enforce access control (who gets credentials) for connecting engines. The key architectural difference is in fine-grained policy enforcement: Horizon enforces Snowflake-defined policies (masking, row access) for external engines (GA for Spark, expanding), while UC enforces Databricks-defined policies (masking, row filters) natively on Databricks compute. When an engine crosses the boundary (Snowflake reading UC via CLD, or Spark reading Horizon), fine-grained policies from the remote catalog do not automatically carry over — each platform enforces its own policies on its own compute. For multi-engine environments, this means fine-grained governance policies must be managed in both systems or converge on a single catalog as the policy authority.

Bidirectionality — what it means

"Bidirectional" gets used loosely. Here's what it actually means:

Horizon as owner:

• Snowflake ↔ any REST-compatible engine: Bidirectional reads and writes (writes in preview)
• Snowflake ↔ Databricks: Reads work via Apache Spark™; native Databricks catalog integration not announced
• Snowflake ↔ Glue: Snowflake reads and writes to Glue-managed tables (GA Oct 2025); Glue engine cannot write to Horizon (engine limitation)
• Snowflake ↔ Azure Fabric: Bidirectional reads (GA Jan 30, 2026)

Unity Catalog as owner:

• Databricks ↔ UC: Full bidirectional, native
• Snowflake ↔ UC-managed tables: Reads and writes via catalog-linked database (GA Oct 2025); UC governance applies on Databricks side; Snowflake-native governance (masking, tags) can be applied independently on CLD tables.
• Spark ↔ UC: Read/write via REST configuration

The key difference: With Horizon, the limitation is one engine (Databricks native integration not announced) — every other REST-compatible engine gets governed read/write. With UC, Snowflake can read and write via CLD, but specific platform features (Dynamic Tables, Cortex AI, Data Sharing) are unavailable on those tables. Snowflake-native governance (masking policies, tags) can be applied to CLD tables, though row access policies and some advanced constructs have limitations.

Feature trade-offs: What you lose with UC

When UC owns the table, these Snowflake capabilities are not available:

• Dynamic Tables: Automatically refreshed derived tables
• Cortex AI: Automated AI workflows using Dynamic Tables are not supported on CLD tables (Cortex AI functions can query CLD data directly)
• Data sharing / Marketplace: Governed sharing without copying data
• Row access policies: Limited support on catalog-linked database tables (masking policies and tags are supported; certain policy constructs and platform-managed capabilities have restrictions)

When Horizon owns the table, all of the above work natively — plus governance extends to every engine.

Access control: Identity vs. authorization

Identity: Centralizable today. Both Snowflake and Databricks support SCIM provisioning from a common IdP (Entra ID, Okta). Users and groups sync automatically to both platforms.

Authorization: Not federated. A GRANT in UC has no effect in Snowflake and vice versa. Each platform maintains an independent privilege model. There is no native sync.

Both catalogs enforce access for connecting engines. The difference is enforcement depth: Horizon provides GA policy enforcement for Spark (via connector) and native enforcement for Snowflake. UC provides native enforcement for Databricks and exposes an Iceberg REST endpoint that other engines (including Snowflake CLD) can consume. In both cases, governance does not federate across the boundary — each platform enforces its own policies. If your environment requires a single policy authority across diverse engines, evaluate which catalog your highest-governance workloads run on.

Summary

The recommendation

For multi-engine environments where diverse compute (Apache Spark™, Apache Flink®, DuckDB) needs governed read/write access to a shared catalog, Horizon's architecture is purpose-built for that use case.

If Databricks is your system of record and you don't run significant Snowflake workloads, Unity Catalog is the natural choice.

For dual-platform organizations: Use Horizon for Snowflake-originated data and Unity Catalog for Databricks-originated data. This avoids limiting either platform's access to its native capabilities.

Source documentation

• Horizon Catalog — External engine access — supported engines, read/write, authentication
• Governance enforcement from Spark — policy enforcement semantics
• Catalog-linked databases — CLD capabilities and limitations
• Externally managed writes — DML on external tables
• Bidirectional access with Unity Catalog

Pattern Walkthroughs (with demos)

• Connect Databricks UC to Snowflake via Iceberg REST
• External-First CLD — UC owns, Snowflake reads
• SF-Managed Iceberg — Horizon owns, external engines read
• CLD + Cortex AI — AI functions on CLD data
• Write Once Read Many — Reverse — Snowflake writes, Databricks reads

Release Notes:

• External engine reads GA — Feb 6, 2026
• External engine writes Preview — Mar 16, 2026
• CLD + external writes GA — Oct 17, 2025
• Fabric bidirectional GA — Jan 30, 2026
• Governance enforcement GA — Jan 27, 2026