5.4 Delta Sharing

Quick Answer: Delta Sharing is an open protocol for sharing live data across platforms and organizations without copying it. A provider packages assets into a share and grants it to a recipient. Two modes exist: Databricks-to-Databricks (UC recipients; uniquely supports notebooks, volumes, and models) and open sharing (any client, via bearer-token credentials).

What Delta Sharing Is

Delta Sharing solves cross-organization data exchange. Traditionally you would FTP files, replicate to a recipient's system, or stand up a custom API — all of which copy data, drift out of date, and create governance gaps. Delta Sharing instead exposes live, read-only access to data in place: the recipient queries the provider's data through the protocol and always sees the current version, with no replication. Because it is an open protocol (with open-source clients for pandas, Spark, Power BI, and more), the recipient does not need to be a Databricks customer — a key differentiator the exam emphasizes.

Shares and Recipients

Two objects define a sharing relationship, and both are Unity Catalog securables:

The workflow: an admin creates a share, adds assets to it, creates a recipient, and grants the share to that recipient. Privileges like CREATE SHARE, USE SHARE, and CREATE RECIPIENT govern who can do this. The provider keeps full control — they can add or remove assets and revoke the share at any time, and all recipient access is captured in audit logs.

Two Sharing Modes

Databricks-to-Databricks (D2D) sharing is used when the recipient also has a Unity Catalog-enabled Databricks workspace (on any cloud — AWS, Azure, or GCP). It is the most secure mode because identity is managed through UC on both sides, with no tokens to distribute. D2D is also the way to share across different metastores in your own account. Critically, D2D is the only mode that can share notebooks, volumes, and models — open sharing supports tables and views only.

Open sharing is used when the recipient is not a Databricks user or lacks a UC-enabled workspace. The provider issues bearer-token credentials (or uses OIDC federation) that any Delta Sharing client can use to read the data.

Remember: the deciding factor between modes is whether the recipient is on Unity Catalog.

The Sharing Workflow and Providers

Delta Sharing introduces a small set of objects beyond shares and recipients. On the consuming side, a provider object represents the organization you are receiving data from; the recipient mounts the provider's shares as a catalog and queries them in the normal three-level namespace. Privileges such as CREATE PROVIDER, USE PROVIDER, CREATE RECIPIENT, and USE RECIPIENT govern these flows.

A typical provider workflow:

1. CREATE SHARE sales_share;
2. ALTER SHARE sales_share ADD TABLE prod.sales.orders;
3. CREATE RECIPIENT partner_co; (Databricks generates a credential or links a UC sharing identifier)
4. GRANT SELECT ON SHARE sales_share TO RECIPIENT partner_co;

The recipient then sees a read-only catalog and queries the live data. Because access is read-only and in place, the provider never loses control of the source.

Governance and Security of Shares

Everything a recipient does is captured in audit logs, so the provider can see exactly which shared tables were read and when. The provider can revoke a share or rotate credentials at any time, immediately cutting off access. For open sharing, the bearer token is the credential, so it must be transmitted securely and rotated periodically; this is why Databricks-to-Databricks sharing — which uses managed UC identity instead of tokens — is considered the more secure mode when both parties are on Unity Catalog.

Delta Sharing also supports sharing across metastores within one account, which is how large enterprises move data between regional metastores without copying it.

Why Delta Sharing Matters for the Exam

The core idea to retain is that Delta Sharing breaks the historical trade-off between sharing data and keeping control of it. Old approaches forced a copy — once a partner had your file, you could not govern it, and it was stale the moment it left. Delta Sharing's open protocol gives recipients live, read-only access in place, so the provider keeps governance, the data is always current, and access is fully audited and revocable.

The single decision that drives implementation is whether the recipient is on Unity Catalog: if yes, Databricks-to-Databricks sharing uses managed identity and unlocks notebooks, volumes, and models; if no, open sharing issues a bearer token (or OIDC) that any open-source client can consume for tables and views. Do not confuse Delta Sharing with Lakehouse Federation — Sharing is outbound distribution of your data, while Federation is inbound querying of others' systems. Both avoid copying data, but they solve opposite directions of the interoperability problem.