D2O sharing
Databricks-to-Open (D2O) sharing lets you share data with recipients on any platform, whether they use Databricks or not. This page covers best practices for D2O sharing. For step-by-step setup instructions, see Share data using the open sharing protocol.
- Share with any platform supporting the open OpenSharing protocol
- Unity Catalog managed Delta/Iceberg tables and views only
- Volumes, models, and notebooks are not supported (D2D only)
- Two authentication patterns: bearer tokens and OIDC federation
Authentication
Bearer tokens
- Configure token lifetimes at the metastore level
- Rotate tokens regularly
- Use recipient IP access lists for additional control
OpenID Connect (OIDC) federation
- Sharing service authenticates and returns pre-signed file URLs (temporary, time-limited access to storage)
- Recipients read directly from provider storage (with the exception of shared views, provider compute is not used)
- Encourage recipients to automate token refresh for OIDC flows
Best practices
Egress and costs
- Providers may incur egress fees when recipients read data
- Plan for higher egress with D2O since external recipients cannot leverage Databricks optimizations
For mitigation strategies (CDF, Cloudflare R2, replication), see Egress considerations.
Connector compatibility
Recipients must use compatible connectors for advanced features:
| Feature | Minimum version |
|---|---|
| Deletion vectors and column mapping | delta-sharing-spark 3.1+ or DBR 14.1+ |
| CDF and streaming reads | DBR 14.2+ |
Recommend pinning connector versions for stability.
Governance and access control
- Shares, recipients, and grants are managed via Unity Catalog
- Removing grants or recipients immediately blocks access
- Manage permissions via
GRANT ON SHAREor Catalog Explorer - Use IP access lists for stronger boundaries
Dynamic views in D2O
Unlike D2D, dynamic views in D2O materialize on the provider side before sending to recipients.
- Provider incurs compute for filtering and temp storage costs
- Consider the cost implications for high-volume or complex view logic
- For cost-sensitive scenarios, consider partitioned table sharing instead of dynamic views
D2O operations
- Maintain processes for token rotation and revocation
- Schema changes may propagate differently than D2D; coordinate with recipients in advance
- Monitor connector versions used by external recipients for compatibility
For general operations guidance (change management, health checks, governance), see the Operations runbook.
What's next
- Learn about D2D sharing patterns for Databricks-to-Databricks
- Learn about O2D sharing patterns for consuming external shares
- Explore bi-directional sharing for two-way collaboration
- Set up recipients and authentication
- Configure monitoring to track sharing activity