Concept card

Databricks Unity Catalog — Data Sharing (External + Internal)

As of 2026-07-24T14:00:00Z

Edited by Cédric-Olivier Mâry, sole editor and publication director — 27 years in the SAP ecosystem. How these pages are produced, and where automation is used.

What is Databricks Unity Catalog — Data Sharing (External + Internal)?

Unity Catalog's two sharing modes trade cost against reach: Databricks-to-Databricks is cheapest since both sides speak Unity Catalog natively, while Open Delta Sharing costs more governance overhead but reaches SAP Datasphere or Snowflake.

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.
Databricks Unity Catalog — Data Sharing (External + Internal) is mastered only when it changes a named buyer decision.
Start with the semantic contract and control model before demonstrating the tool.
Use current SAP, analyst, study, KG, and news signals as evidence, not decoration.
Separate verified facts from directional trends and modeled assumptions.
Define owner, metric, threshold, support path, and rollback before scaling.

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.
Decision owner: The accountable person who accepts the trade-off and funds the next action.
Semantic contract: The shared definition of business terms, metrics, entities, and access rules used by tools and teams.
Control plane: The layer that applies policy, access, lineage, monitoring, and escalation across the operating model.
Evidence grade: A label that separates verified fact, directional signal, modeled assumption, and field observation.

Sources

Full card available to members. What the full card adds: the full decision framework · the SAP vs Snowflake / Databricks / Fabric comparison · the common pitfalls and their fix · the cheat sheet · the architecture schemas · the code blocks · the facts worth quoting.

Open in the app →