Skip to main content

Sharing patterns

Delta Sharing supports multiple sharing patterns depending on whether your recipients are on Databricks or external platforms. The pattern you choose affects which asset types you can share and how authentication is handled. For a comprehensive overview of the protocol, see What is Delta Sharing?

Pattern comparison​

PatternProviderRecipientAuthenticationAsset types
D2DDatabricksDatabricksUnity Catalog Sharing IdentifierTables, views, volumes, notebooks, models, MCP
D2ODatabricksExternal platformBearer tokens or OIDCTables, views only
O2DExternal platformDatabricksBearer tokens or OIDCTables (via ingestion)

Databricks-to-Databricks (D2D)​

D2D sharing provides the richest feature set with native Unity Catalog integration. Recipients connect using their sharing identifier with no token exchange required. All asset types are supported, including volumes, notebooks, and models.

Best for: Sharing with customers who are already on Databricks.

Learn more about D2D patterns →

Databricks-to-Open (D2O)​

D2O sharing uses the open Delta Sharing protocol to share data with recipients on any platform that supports the protocol. Authentication is handled via bearer tokens or OIDC federation.

Best for: Sharing with external platforms, non-Databricks users, or broad distribution.

Learn more about D2O patterns →

Open-to-Databricks (O2D)​

O2D patterns involve bringing external data into Databricks, typically through Lakeflow Connectors or other ingestion mechanisms. This is the inverse of the provider patterns covered in this guide.

Best for: Consuming data from external providers.

Learn more about O2D patterns →

Bi-directional sharing​

Some use cases require both sharing data out and consuming data in. Bi-directional patterns combine D2D/D2O outbound sharing with O2D ingestion.

Best for: Two-way data collaboration, data exchanges, and hub-and-spoke architectures.

Learn more about bi-directional patterns →

What's next​