Databricks Unity Catalog — Data Sharing (External + Internal)

Unity Catalog is Databricks' unified governance layer — the single catalogue that tracks every table, view, model, and file, who can touch it, and how it traces back to source. Data Sharing is the surface of Unity Catalog that lets one Databricks account expose curated, governed assets to other consumers without copying the underlying data, and by 2026 it is the standard way SAP analytics estates interoperate with a Databricks lakehouse — which is precisely why BDC ships a native Databricks integration built on this mechanism rather than a custom pipe.

Why it matters

Most enterprise clients running SAP analytics are not running SAP alone; Databricks, Snowflake, and Fabric routinely sit alongside Datasphere in the same landscape. An architect who cannot explain how governed, read-only sharing works across that boundary — without proposing a nightly batch export as the answer — will lose credibility on any multi-platform engagement. Unity Catalog Data Sharing is also the mechanism most directly comparable to SAP's own Delta Sharing support in Datasphere and BDC Connect, so understanding it sharpens the comparison rather than replacing it.

Why it matters in practice

• SAP Datasphere plus Databricks is the canonical 2026 multi-engine pattern this feature is built to serve.
• Sharing is read-only by design — high-write transactional integration needs Lakehouse Federation or native connectors instead.
• Revocation is immediate and rotation is a single CLI call, so access control is operationally cheap once a share is set up.

Key points

• Two modes — Databricks-to-Databricks (full UC semantics + lineage) and Open Delta Sharing (any compliant client, including SAP Datasphere as consumer).
• Share contents — tables, views, volumes, models; column selection + row filters + change-data-feed (CDF) toggle per recipient.
• Auth — bearer tokens for open protocol; recipient account identifier for Databricks-to-Databricks; immediate revocation; one-call rotation.
• Lineage — UC tracks every share and recipient; full audit log of who read what when, including which rows the filters delivered.
• Read-only — no write-back via Sharing; for write-integration use Lakehouse Federation or native connectors.
• 2026 protocol update: eligible Delta tables now support directory-based access in Delta Sharing — the recipient reads directly from cloud storage with temporary credentials instead of per-file pre-signed URLs, cutting latency for repeated large scans.
• 2026 protocol update: foreign Iceberg tables federated from external Iceberg catalogs can now be added to a share and read (read-only) by any Delta Sharing-compliant recipient — a share is no longer limited to Delta-native provider-side tables.
• A Databricks-to-Databricks or Delta-Sharing share becomes visible to Joule's SAP Knowledge Graph grounding only once it is re-published as a Datasphere data product — reading a share into Datasphere is not the same step as exposing it to Joule.

Terms used on this page

Unity Catalog

Databricks' unified governance layer for tables, views, volumes, ML models, and files; centralises access control, lineage, and audit across all Databricks workspaces in an account.

Share

A named UC object listing the tables, views, volumes, or models exposed to one or more recipients; column visibility and row filters set per recipient.

Change-data-feed (CDF)

An optional Delta-table feature that captures row-level INSERT/UPDATE/DELETE events for downstream incremental consumption; can be exposed via Sharing for incremental reads.

Lakehouse Federation

The Databricks pattern for querying external data sources (PostgreSQL, MySQL, Snowflake, SAP HANA via JDBC) in place from Databricks SQL; complementary to Sharing — federation is for bidirectional/in-place, Sharing is for read-only governed publication.

Directory-based access mode

A 2026 Delta Sharing enhancement: instead of per-file pre-signed URLs, the sharing response includes the table's cloud storage location plus temporary credentials, letting a supporting recipient read directly from cloud storage.

Foreign Iceberg table sharing

A 2026 Delta Sharing capability: Iceberg tables federated from an external Iceberg catalog can be added to a share and read (read-only) by any Delta Sharing-compliant recipient, extending Sharing beyond Delta-native provider-side tables.

Mosaic AI Agent Framework

Databricks' native multi-step agent runtime (C173); reads Unity Catalog-governed tables, volumes and registered models, including those exposed via a Databricks-to-Databricks share, inheriting the same column-level permissions.

Sources

1. Databricks documentation — Unity Catalog Data Sharing
2. Delta Sharing protocol specification
3. SAP + Databricks joint architecture guidance
4. Databricks — What is Delta Sharing? (official docs)
5. Databricks — Access Databricks data using external systems
6. Databricks — What is OpenSharing?
7. Databricks — Unity Catalog table types (managed vs external)
8. Databricks — Unity Catalog managed tables for Delta Lake and Apache Iceberg
9. Databricks on Microsoft Azure — April 2026 release notes (directory-based access mode, foreign Iceberg table sharing)
10. Databricks — Unity Catalog product page
11. SAP Help Portal — Business Data Cloud Connect for Databricks
12. Databricks Docs — October 2026 platform release notes (cross-engine ABAC GA 1 Oct; JDBC Unity Catalog connections GA 2 Oct)
13. Databricks Docs — Create and manage row filter and column mask policies (ABAC) in Unity Catalog
14. Databricks Docs — Create data recipients for OpenSharing (Databricks-to-Databricks)
15. Databricks Docs — Audit and monitor data sharing
16. Databricks Docs — Unity Catalog best practices (cross-region sharing, managed tables)
17. CIO — Microsoft, Google back Apache Ossie to make enterprise data and AI platforms more interoperable