Delta Lake UniForm Gives Snowflake Access to Databricks Tables Without Copying

Teams that need Snowflake to query Databricks-owned data face a practical choice: copy it on a schedule or connect the platforms directly. Delta Lake UniForm, Unity Catalog and private connectivity offer a path to access without a second dataset or nightly export job. That choice affects more than storage: it shapes how quickly changes become available, how many pipelines teams must maintain, and where they need to investigate when a query fails. Direct access can reduce duplication, but it doesn't make the underlying platforms identical. The work shifts from keeping copies in sync to configuring formats, catalog permissions and network paths correctly.

Why direct access takes extra work

Delta Lake and Apache Iceberg both describe open table formats, but they track files, schemas and change history differently. Delta Lake is Databricks’ native format, while Snowflake has strong native support for Iceberg. As a result, Snowflake can’t directly open a table written as Delta Lake, and Databricks can’t read another engine’s Iceberg table as Delta. UniForm and catalog access address this interoperability gap; the key is configuring the pieces to work together.

A table format is more than a label attached to a folder of data files. It provides rules and metadata that tell a query engine which files belong to a table, what their columns mean, and which changes are part of the current table state. Engines can share the underlying files only when they can interpret the relevant metadata and agree on how to read the table. If they disagree, a directory full of data may be visible while the table itself remains unusable or incomplete.

That distinction explains why copying data has remained a common integration pattern. An export job can transform or package information into a form the destination understands, then deliver it on a schedule. The tradeoff is delay: the destination may query yesterday’s or last hour’s version, depending on the job. Copies also bring their own operational chores, including monitoring transfers, handling failures, and reconciling differences when an export is repeated or interrupted.

What UniForm and Unity Catalog contribute

UniForm is intended to make Delta Lake table data available through Iceberg-compatible metadata, so a system with Iceberg support can work with the table without requiring a separate copy of the underlying data. That can simplify a particular connection between Databricks and Snowflake. It doesn't mean every table, feature, or operation is automatically interchangeable across the two systems. Teams still need to confirm that the table configuration and the operations they depend on fit the access path they plan to use.

Unity Catalog provides the catalog layer in this arrangement. A catalog helps engines discover tables and obtain information about their metadata; it also plays a role in controlling access. The practical point is that file visibility alone isn't enough. Snowflake needs a supported way to find and interpret the table, while the identity used for access must be permitted to reach the relevant resources. A setup can therefore fail even when the data files exist and the format appears compatible.

This is where the integration becomes a systems problem, not just a file-format problem. Teams need to consider how table metadata is exposed, which permissions apply, and whether the network path allows the querying service to reach the necessary endpoints. Private connectivity addresses the network portion by providing a private route between services, where supported and configured. It doesn't grant table permissions or resolve incompatible metadata by itself. Three pieces, each with a distinct job.

The operational tradeoff

Direct access can reduce duplicate storage and avoid a scheduled export pipeline, but those savings shouldn't be confused with zero maintenance. Someone still owns the connection, catalog setup, permissions and troubleshooting. A change to table settings or access policy can affect the consumer, and teams need enough visibility to determine whether a problem comes from query behavior, metadata discovery, authorization or connectivity. The architecture may be simpler on a diagram while still requiring careful operational ownership.

There can also be a difference between reading data and supporting every workflow a team might associate with a table. Cross-platform access is often most straightforward when the consumer needs to query shared data. Requirements around writing, updates, schema changes or specialized table behavior deserve separate validation. If you're working in this space, map the actual operations your users need before treating “interoperable” as a blanket guarantee.

That said, a scheduled copy can still be the better fit when teams need a transformed destination dataset, a deliberately delayed snapshot, or a clear boundary between production systems. A copy may also make sense when the direct path doesn't support a required behavior or when the network and catalog arrangements aren't available. The decision is about the whole workflow: freshness, transformation, access control, reliability and who responds when something breaks.

Implications for data teams

The broader significance is that open table formats can reduce friction between data platforms, but only when their surrounding metadata and access systems line up. The files are one layer. Catalog discovery, identity and network reachability are others. This is more significant than it looks: interoperability is less a switch than a contract between systems, and each side has to honor the parts of that contract the workload depends on.

For teams evaluating this pattern, the useful test is concrete. Pick representative tables, confirm that Snowflake can discover and query them through the intended catalog path, and verify that the access controls match the desired users and services. Check how changes to the Databricks-owned data appear to the reader, and document which operations are supported in the setup. Those checks turn a promising architecture into an operational decision.

(And this is the part most people overlook.) Removing a nightly export can remove a synchronization task, but it also makes the live relationship between systems more important. A failure in discovery or connectivity can affect the consumer directly, instead of merely delaying the next copy. Teams should decide how they'll detect and diagnose that failure before relying on the connection for important work.

What to watch next

The value of this approach will depend on how well the format, catalog and connectivity capabilities fit a team's existing environment. Support can vary by configuration and by the actions users expect to perform, so claims of broad compatibility need to be checked against the actual workload. The sensible outlook is measured: direct access can remove avoidable duplication and stale exports, while leaving real integration work around metadata, permissions and operations.

For data teams, the payoff is not simply fewer files. It’s a cleaner path from the system that owns a table to the system that needs to analyze it, provided both platforms can agree on what the table contains and who may read it. The promise is useful. The setup is the product.