Delta Sharing (now OpenSharing) explained

Delta Sharing is the Databricks open protocol for giving another organization read-only access to live data without copying it. Current Databricks documentation has renamed the feature OpenSharing, so exam material may use either name. The decision rule for exams: a partner who needs ongoing access to your data without an export and without joining your workspace points to Delta Sharing. If the recipient also has a Unity Catalog-enabled Databricks workspace, use Databricks-to-Databricks sharing, and if they are on any other platform, use open sharing.

What the name change means for your exam

The Azure Databricks documentation page at the old /delta-sharing/ address now redirects to a page titled “What is OpenSharing?”. The open-source project lives at opensharing.io, and its protocol specification is still hosted in the delta-io/delta-sharing repository. The Spark reader syntax in the documentation still uses format("deltaSharing"). The exam outlines are in transition:

Treat the two names as the same feature. The abbreviations D2D (Databricks-to-Databricks) and D2O (Databricks-to-Open) are the ones that matter.

Three objects and two ways to connect

The vocabulary is the same in both modes.

• A provider shares data. To use the built-in server and manage shares through Unity Catalog, the provider needs at least one Unity Catalog-enabled workspace.
• A share is a read-only collection of data assets. The provider can add or remove assets and change recipient access at any time.
• A recipient is the named object that represents the consuming organization and ties it to a credential or sharing identifier.

Sharing between workspaces on the same Unity Catalog metastore needs no Delta Sharing at all, because Unity Catalog already controls access across those workspaces. Recipients get read-only access either way, and shared notebooks can be cloned into the recipient’s own workspace.

Worked example: sharing a Gold table with a partner

Contoso wants to give Fabrikam, who run Databricks on another cloud, the table prod.sales.daily_revenue. The provider side, run by a metastore admin or a user with the right privileges:

CREATE SHARE IF NOT EXISTS partner_sales;
ALTER SHARE partner_sales ADD TABLE prod.sales.daily_revenue;
CREATE RECIPIENT IF NOT EXISTS fabrikam USING ID 'azure:westeurope:<metastore-uuid>';
GRANT SELECT ON SHARE partner_sales TO RECIPIENT fabrikam;

Fabrikam sends its sharing identifier (cloud, region and metastore UUID) first, which is why the recipient is created USING ID. The share owner needs USE CATALOG, USE SCHEMA and SELECT on what is added, and CREATE SHARE on the metastore is needed to create the share. SELECT is the only privilege you can grant on a share.

On the recipient side, a user with CREATE CATALOG and USE PROVIDER makes the share visible:

CREATE CATALOG IF NOT EXISTS contoso_sales USING SHARE contoso.partner_sales;

From then on the table is queried as contoso_sales.sales.daily_revenue, read-only. If Fabrikam were not on Databricks, the recipient would instead be created with a bearer token or OIDC federation, and Fabrikam would read the data with an open connector. Adding the table WITH HISTORY also lets recipients run time-travel and streaming reads. Revoking access is REVOKE SELECT ON SHARE partner_sales FROM RECIPIENT fabrikam.

Costs, limits and neighbors

No data is replicated, so sharing within a region has no egress charge; sharing across clouds or regions can incur cloud egress fees. Providers cannot share tables that have row filters or column masks, but dynamic views can restrict rows and columns per recipient. Tables must be Delta or managed Iceberg. Two neighbors are easy to confuse with sharing: Clean Rooms let several parties analyze combined data without exposing raw tables, and Lakehouse Federation is inbound, querying an external system in place. Sharing is also the basis of Databricks Marketplace. Governance of the shared objects builds on Unity Catalog and the table format is covered in Delta Lake explained.

Which exams test this

The Data Engineer Professional outline changed on October 9, 2026; the previous outline had Sharing and Federation as its own section.

How the questions are built

Scenarios describe an outside party and add constraints. “No workspace accounts” and “no copies leaving our control” rule out exports, shared credentials and partner logins. “The partner uses Power BI or pandas” points to open sharing; “the partner has a Unity Catalog workspace” points to D2D, and when the answer lists notebooks, volumes or models, only D2D can share them. “Short-lived credentials” or “partner’s identity provider” suggests OIDC federation over a bearer token. A frequent trap is Lakehouse Federation, which pulls external data in, offered for a requirement that sends your data out. Another is Clean Rooms offered when the partner simply needs read access to tables. A secure strategy means sharing only the tables needed, one recipient per party, token expiry and access monitoring through audit logs.

Go deeper

• What is OpenSharing? (Microsoft Learn, formerly Delta Sharing)
• Create shares and manage access to shares
• Read data shared using Databricks-to-Databricks sharing
• OpenSharing open-source project
• Related on this site: Lakeflow Declarative Pipelines, medallion architecture for the Gold tables you usually share, and the DP-750 study plan