how does Delta Sharing work with Unity Catalog

Summary

• OpenSharing (formerly Delta Sharing) is the secure data sharing platform in Databricks, built on an open protocol. Unity Catalog holds the objects behind it: a share (the collection of assets), a recipient (who receives them), and the privileges and audit logs around both.
• A provider creates a share, adds tables, views, volumes, or other assets, creates a recipient, and grants that recipient SELECT on the share. Recipients get read-only access, and sharing does not require replicating the data.
• Recipients with a Unity Catalog-enabled Databricks workspace create a catalog from the share. Everyone else connects with a bearer-token credential file or OIDC federation.
• Row and column restrictions come from dynamic views that use CURRENT_RECIPIENT() or from partition filters, not from Unity Catalog row filters, column masks, or ABAC policies. Provider audit logs land in system.access.audit.

how does Delta Sharing work with Unity Catalog

The open Delta Sharing protocol lets a provider share live data without copying it. Databricks delivers it as OpenSharing, and Unity Catalog is the governance layer underneath: a share and a recipient are Unity Catalog securable objects, and you grant a recipient SELECT on a share. The recipient reads the shared data through temporary credentials, so sharing does not require replicating the data.

What are the building blocks in Unity Catalog?

Object	What it is	Privileges to know
Share	A read-only collection of data and AI assets, such as tables, views, materialized views, metric views, volumes, models, and notebooks	CREATE SHARE on the metastore. The share owner needs USE CATALOG, USE SCHEMA, and SELECT on each table or view
Recipient	The organization or users who receive shares, tied to a credential or a sharing identifier	CREATE RECIPIENT on the metastore
Provider	In the recipient's metastore, the object that represents the sharing organization	CREATE CATALOG plus USE PROVIDER (or provider ownership) to create a catalog from a share
Grant	A recipient's access to a share. SELECT is the only privilege	Metastore admin, or ownership or delegated privileges on both the share and the recipient

How does a provider share data?

Create the share, add assets, and grant the recipient access:

CREATE SHARE IF NOT EXISTS <share-name>;
ALTER SHARE <share-name> ADD TABLE <catalog-name>.<schema-name>.<table-name> WITH HISTORY;
GRANT SELECT ON SHARE <share-name> TO RECIPIENT <recipient-name>;

WITH HISTORY lets recipients run time travel queries and Structured Streaming reads. ALTER SHARE ... ADD SCHEMA shares a whole schema, including assets added to it later. You also need a recipient. For one on a Unity Catalog-enabled Databricks workspace, you identify them by the sharing identifier of their metastore, in the form <cloud>:<region>:<uuid>. For anyone else, Databricks generates a credential file that the recipient downloads once from an activation link, or you configure OIDC federation.

How do recipients read the data?

Databricks-to-Databricks. A metastore admin or privileged user creates a catalog from the share. Data under it is read-only, and access to its schemas and tables follows the usual Unity Catalog privilege hierarchy. No token is involved, and only this route supports sharing notebooks, volumes, and models.

CREATE CATALOG IF NOT EXISTS <catalog-name> USING SHARE <provider-name>.<share-name>;

Databricks-to-Open. Recipients authenticate with the bearer-token credential file or through their own identity provider with OIDC federation, then read from Apache Spark, pandas, BI tools, or Databricks. Workspaces on the same Unity Catalog metastore don't need OpenSharing, because Unity Catalog manages that access directly.

How do you restrict rows and columns?

Don't rely on Unity Catalog row filters or column masks to restrict recipients: tables that have them are left out when you share a whole schema, and ABAC policies on a shared asset do not govern the recipient's access. Use a dynamic view instead. Set a recipient property, then filter on it with CURRENT_RECIPIENT():

ALTER RECIPIENT recipient1 SET PROPERTIES ('country' = 'CA');

CREATE VIEW my_catalog.default.view1 AS
  SELECT * FROM my_catalog.default.my_table
  WHERE country = CURRENT_RECIPIENT('country');

You can also share only some partitions of a table. Depending on the recipient's compute, views can be queried and temporarily materialized on the provider side, which can add compute and storage cost.

What do freshness, cost, and revocation depend on?

OpenSharing does not require data replication, but your cloud vendor might charge egress when recipients read across clouds or regions. Within a region there is no egress cost. Updates to shared tables and volumes appear in near real time on the recipient side. To end access, run REVOKE SELECT ON SHARE <share-name> FROM RECIPIENT <recipient-name>.

FAQs

Is it secure?

Open recipients authenticate with a bearer-token credential or OIDC, and Databricks manages authentication for Databricks-to-Databricks sharing. Access is read-only, and reads use temporary credentials such as pre-signed URLs or scoped cloud tokens. Bearer-token lifetime defaults to a metastore setting, and you can rotate tokens.

Can the recipient modify the shared data?

No. Recipients get read-only access. Shared notebooks can be cloned and then edited in the recipient's workspace.

How is this different from exporting data?

Sharing does not copy data to the recipient. For tables, recipients read the provider's files through temporary credentials, and updates appear in near real time.

Can I see who accessed a share?

Yes, once system tables are enabled. Provider audit logs in system.access.audit record recipient activity, with events such as deltaSharingQueriedTable.

Can I share volumes, not just tables?

Yes, with Databricks-to-Databricks sharing. Volumes, models, and notebooks are not available to Databricks-to-Open recipients.