OpenSharing: Databricks-to-Databricks vs Databricks-to-Open Sharing

Implement OpenSharing (D2D and Databricks-to-Open) and Clean Rooms for privacy-preserving collaboration.

11 min read

2.4% of exam

6 sources

Published 2 Oct 2026

Docs as of 30 Sep 2026

What you will be able to do

Explain how shares, providers and recipients work as Unity Catalog securables
Create a Databricks-to-Databricks recipient from a sharing identifier and expose a share to recipient users as a read-only catalog
Choose bearer-token or OIDC federation authentication for a Databricks-to-Open recipient and manage token lifetime
Pick the right sharing protocol based on the recipient's platform and the asset types being shared

Key concept

The recipient decides the protocol — OpenSharing gives a Unity Catalog provider two built-in protocols. Who the recipient is decides which one you use. If the recipient has a Unity Catalog-enabled Databricks workspace, use Databricks-to-Databricks sharing, which needs no tokens. If they don't, you must use Databricks-to-Open sharing, which authenticates with a bearer token or OIDC federation.

1.Shares, providers and recipients

OpenSharing is the Databricks platform for sharing data and AI assets with people outside your organization. It is also what Databricks Marketplace and Clean Rooms are built on. Every OpenSharing setup has three parts. A share is the package of data. A provider is the organization that shares it. A recipient is the named object that represents whoever receives it.

In a Unity Catalog-enabled workspace, a share is a read-only collection of tables and table partitions, registered as a Unity Catalog securable. You can add or remove tables, streaming tables, managed Iceberg tables, views, materialized views, metric views, volumes, models and notebook files at any time. You can also grant or revoke a recipient's access at any time. Some asset types are limited by the protocol: notebook files, views (including dynamic views), volumes and models can be included only when the recipient uses a Unity Catalog-enabled Databricks workspace.

Because shares and recipients are securables, access ends as soon as you delete one. Dropping a share cuts off every recipient of that share. Deleting a recipient removes its access to every share it held. One recipient can hold many shares. Recipients are scoped to a metastore, so sharing from several metastores means creating the recipient once in each.

Checkpoint 1 of 7· Check yourself

A provider drops a share from its Unity Catalog metastore. Five recipients had been granted that share. What happens?

Sources1

D2D sharing uses the OpenSharing server built into Databricks. It works with any recipient who has a Unity Catalog-enabled workspace, whatever their account or cloud. It also suits sharing between different metastores inside your own account. Between metastores in the same account, D2D is always on, so you don't need to enable OpenSharing on the metastore. You need that step only when sharing with other accounts or with non-Databricks clients.

To create a D2D recipient you need the CREATE RECIPIENT privilege on the metastore (or be a metastore admin). The recipient gets authentication type DATABRICKS and is identified by the sharing identifier of the recipient's metastore, in the format <cloud>:<region>:<uuid>. The shared data can be accessed only on that metastore.

Checkpoint 2 of 7· Fill the gap

Which keyword completes this statement, which creates a Databricks-to-Databricks recipient from a metastore sharing identifier?

CREATE RECIPIENT [IF NOT EXISTS] <recipient-name>
USING  ?  '<sharing-identifier>'
[COMMENT "<comment>"];

Tables are added to a share with ALTER SHARE. You can add a partition clause to share only part of a table, or an alias. When an alias is set, recipients must query the table by that name. The history option has a big effect on D2D performance. Sharing history lets recipients use time travel and Structured Streaming. It also lets Databricks hand out temporary cloud credentials scoped to the table's root directory, which gives performance comparable to reading the source table directly. Partitioned tables don't get this performance benefit. If recipients will query the change data feed with table_changes(), enable CDF on the table before you share it WITH HISTORY.

Adding a table to a share, with an optional partition filter, alias and history settingsql

ALTER SHARE <share-name> ADD TABLE <catalog-name>.<schema-name>.<table-name>  [COMMENT "<comment>"]
   [PARTITION(<clause>)] [AS <alias>]
   [WITH HISTORY | WITHOUT HISTORY];

On the recipient side, the share shows up in their workspace. Before anyone can query it, a metastore admin or another privileged user has to create a catalog from the share. After that, privileges are granted the same way as for any other Unity Catalog catalog, with one restriction: objects in a shared catalog can only ever be granted read access. Shared notebooks sit at the catalog level, so anyone with USE CATALOG on the catalog can open them.

Checkpoint 3 of 7· Put it in order

Put the steps that take a D2D share from provider grant to an analyst's query in order.

1.The provider grants the recipient access to the share
2.Users are granted read privileges on the catalog and its objects
3.The share becomes available in the recipient's Databricks workspace
4.A metastore admin or privileged user creates a catalog from the share

Checkpoint 4 of 7· Exam question

A partner company has no Databricks workspace at all and only needs continuous read access to a single Delta table through their Power BI reports. Which approach satisfies this requirement with the least operational overhead for the provider?

Sources1 2 3 4

D2O sharing makes Unity Catalog-managed tabular data available to users on any platform, including Apache Spark, pandas and Power BI. The provider has two ways to authenticate the recipient.

- Bearer token. Databricks generates a token and a credential file, and the recipient is created with authentication type TOKEN. The provider sends an activation link over a secure channel, or lets Databricks email it. The recipient downloads the credential file and uses it to read the data. The provider can refresh or revoke the token. - OIDC federation. The recipient's identity provider handles authentication according to a policy the provider creates. Databricks exchanges the IdP's JWTs for short-lived Databricks OAuth tokens. You cannot grant an OIDC recipient access by email.

Either way, the shared data is read-only.

Checkpoint 5 of 7· Match them up

Match each D2O concept to what it means

Tap a term, then the definition that fits it.

With bearer tokens, the provider is responsible for keeping them secure. You set the default recipient token lifetime when you enable OpenSharing on the metastore, and Databricks recommends making tokens expire. There is also a fixed deadline: D2O tokens issued before December 8, 2025 that have no expiry, or an expiry after December 8, 2026, will expire on December 8, 2026. IP access lists can restrict recipients further. For eligible Delta tables, D2O uses directory-based access by default. Databricks returns the table's storage location with temporary cloud tokens. Tables that aren't eligible fall back to pre-signed URLs.

Email sharing (Beta) lets you invite a recipient by email address. It is a delivery method layered on the recipient you create, not a separate protocol or authentication type, and it doesn't support OIDC federation.

Checkpoint 6 of 7· Exam question

Following an acquisition, the newly acquired company runs its own Unity Catalog-enabled Databricks workspace in a different region. The data platform team must grant that company near real-time access to a shared table, but with certain business units hidden from view at the row level. Which approach meets both requirements?

Sources5 6

4.Choosing between D2D and D2O

Databricks-to-Databricks vs Databricks-to-Open sharing, from the provider's side

Aspect	Databricks-to-Databricks	Databricks-to-Open
Recipient platform	Unity Catalog-enabled Databricks workspace	Any computing platform (Spark, pandas, Power BI, Databricks)
Recipient authentication	Sharing identifier; no recipient token to manage	Long-lived bearer token or OIDC federation
Shareable assets	Tables plus notebooks, volumes, models and views	Tabular data
Governance extras	Unity Catalog governance, auditing and usage tracking for provider and recipient	Unity Catalog governance on the provider side
Metastore enablement	Not needed between metastores in the same account	Required; sets the default recipient token lifetime

Three cases come up often. First, between workspaces attached to the same metastore you don't need OpenSharing at all, because Unity Catalog grants already cover them. Second, D2D works only within the same environment type. Sharing with Azure Government is not supported, and sharing across regulatory domains such as AWS GovCloud is in Public Preview. D2O, by contrast, works between all cloud environment types. Third, if the share has to include a notebook, volume or model, D2D is the only option.

Checkpoint 7 of 7· Check yourself

A team has two workspaces attached to the same Unity Catalog metastore. Workspace B needs read access to a table in workspace A. What is the right approach?

Sources3 6

Exam traps

Each one states something that sounds right. Open it to see what is actually true.

1.Recipients can be granted MODIFY on a catalog created from a share, just like on any other catalog.Why is that wrong?
Grants on shared catalogs work like other Unity Catalog grants with one exception: objects in a catalog created from a share can only be granted read access.
Covered in Databricks-to-Databricks (D2D) sharing
2.Email sharing is a third protocol and can be combined with OIDC federation.Why is that wrong?
Email sharing is only a way of delivering the invitation for a recipient you create. Email invitations don't support OIDC federation.
Covered in Databricks-to-Open (D2O) sharing
3.Notebooks, volumes and models can be sent to a non-Databricks recipient over Databricks-to-Open sharing.Why is that wrong?
Notebook, volume and model sharing are available only with Databricks-to-Databricks sharing.
Covered in Choosing between D2D and D2O

Sources

Every claim above is drawn from one of these pages, quoted as it was written on the date shown.

1.
https://docs.databricks.com/aws/en/opensharingOfficial docs
“a share is a read-only collection of tables and table partitions that a provider wants to share with one or more recipients”
↩︎ Shares, providers and recipients
“If a provider deletes a recipient from their Unity Catalog metastore, that recipient loses access to all shares it could previously access.”
↩︎ Shares, providers and recipients
“Metastore-to-metastore sharing within a single Databricks account is enabled by default.”
↩︎ Databricks-to-Databricks (D2D) sharing
“does not have access to a Databricks workspace that is enabled for Unity Catalog, you must use Databricks-to-Open sharing.”
↩︎ Key concept
“It isn't a new sharing protocol or authentication type. It's a delivery method layered on the recipient that you create.”
↩︎ Exam trap 2
“Databricks-to-Databricks also supports notebook, volume, and model sharing, which is not available in Databricks-to-Open sharing.”
↩︎ Exam trap 3
“you must define the recipient separately for each metastore”
↩︎ Prediction
“If you remove a share from your Unity Catalog metastore, all recipients of that share lose the ability to access it.”
↩︎ Checkpoint
“granting short-lived Databricks OAuth tokens to the recipient in exchange for JWT tokens that the recipient's identity provider (IdP) passes to Databricks”
↩︎ Checkpoint
“there is no need to use OpenSharing to share data between workspaces attached to the same Unity Catalog metastore”
↩︎ Checkpoint
2.
https://docs.databricks.com/aws/en/opensharing/create-recipientOfficial docs
“identified in the recipient object definition by a sharing identifier string consisting of the metastore's cloud, region, and UUID”
↩︎ Databricks-to-Databricks (D2D) sharing
3.
https://docs.databricks.com/aws/en/opensharing/share-data-databricksOfficial docs
“Tables with partitioning enabled do not receive the performance benefits of history sharing.”
↩︎ Databricks-to-Databricks (D2D) sharing
“Sharing with Azure Government environments is not supported.”
↩︎ Choosing between D2D and D2O
“users can be granted only read access on objects in catalogs that are created from OpenSharing shares”
↩︎ Exam trap 1
“To access the tables, views, volumes, and notebooks in a share, a metastore admin or privileged user must create a catalog from the share.”
↩︎ Checkpoint
4.
https://docs.databricks.com/aws/en/opensharing/create-shareOfficial docs
“you must enable CDF on the table before you share it WITH HISTORY”
↩︎ Databricks-to-Databricks (D2D) sharing
5.
https://docs.databricks.com/aws/en/opensharing/create-recipient-tokenOfficial docs
“The recipient object has the authentication type of TOKEN.”
↩︎ Databricks-to-Open (D2O) sharing
“with no expiration date, automatically expire on December 8, 2026”
↩︎ Databricks-to-Open (D2O) sharing
6.
https://docs.databricks.com/aws/en/opensharing/share-data-openOfficial docs
“Databricks recommends that you configure tokens to expire.”
↩︎ Databricks-to-Open (D2O) sharing
“Databricks returns the table's cloud storage location alongside temporary cloud credentials (cloud tokens) that recipients can use to read data directly from cloud storage.”
↩︎ Databricks-to-Open (D2O) sharing
“Databricks-to-Open sharing is supported between all cloud environment types.”
↩︎ Choosing between D2D and D2O
“the provider sets up authentication using either a long-lived bearer token or Open ID Connect (OIDC) federation”
↩︎ Prediction