Skip to main content

Bi-directional sharing

Some use cases require both sharing data out (D2D/D2O) and consuming data in (O2D). This page covers patterns and considerations for bi-directional data collaboration.

How bi-directional sharing works​

Delta Sharing itself is provider → recipient per share. Bi-directional sharing is achieved by each party acting as both a provider and a recipient.

Each direction is governed independently—separate shares, recipients, catalogs, and entitlements for both sides of the collaboration. There is no implicit "write-back" or symmetric access.

Common use cases​

  • Ad-tech and martech: Exchange audience segments and campaign performance data with partners
  • Financial services: Share risk models, compliance data, and market signals across institutions
  • Industrials: Collaborate on supply chain, operational, and sensor data with vendors and customers
  • Healthcare and life sciences: Exchange clinical data and research datasets with research partners
  • Retail and CPG: Share demand forecasts and inventory data with suppliers

Architecture patterns​

Databricks-to-Databricks (D2D) — most common pattern​

Both parties use Databricks with Unity Catalog enabled. Each side publishes their own Delta tables or views as a share and consumes the other party's share into their own metastore.

  • Each organization creates shares and recipients
  • Unity Catalog manages both inbound and outbound governance
  • Use consistent naming conventions across organizations

Supported assets:

  • Tables, views, and volumes (D2D only)
  • Change Data Feed (CDF) for incremental pipelines
  • Fine-grained row/column security via views

Typical use cases:

  • Partner data collaboration
  • Joint analytics and AI development
  • Enrichment loops (provider shares data → consumer enriches → derived insights shared back)

Hub-and-spoke​

One central "hub" account shares baseline datasets to multiple spokes. Spokes publish derived or enriched datasets back to the hub.

  • Hub manages aggregation, transformation, and redistribution
  • Partners may receive enriched or aggregated data back
  • Centralized governance and audit trail

Enables:

  • Central governance and quality control
  • Distributed feature engineering
  • Marketplace-style ecosystems

Governance and security considerations​

No in-place writes​

Recipients always get read-only access. Any "write-back" is a new table owned by the publishing party. This ensures clear ownership boundaries—each dataset has exactly one owner (the provider), avoiding data corruption and unclear lineage.

Row and column level security​

Fine-grained access is enforced via shared views. Security rules can differ per recipient in each direction, allowing you to tailor what each partner sees.

Auditability​

Query activity is visible via system tables. Each side tracks usage independently, providing a complete audit trail for compliance and monitoring.

Operational considerations​

  • Coordinate schema changes with partners before deployment
  • Monitor both inbound and outbound share health
  • Establish SLAs for data freshness in each direction
  • Use separate service principals for inbound vs outbound operations
  • Define retention and deletion policies for received data
  • Track lineage across both inbound and outbound flows

What's next​