Concept card

SAP Datasphere Delta Sharing

As of 2026-09-27

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

What is SAP Datasphere Delta Sharing?

Delta Sharing lets a Datasphere space publish a live, governed view to Databricks, Fabric, or Snowflake as a read-only Delta table — replacing the old choice between stale nightly extracts and governance-breaking live federation.

What it is

SAP Datasphere Delta Sharing is the open-protocol surface that lets a Datasphere space expose curated data products to external consumers — Databricks, Microsoft Fabric, Snowflake, custom Python clients — without copying the data, without standing up a parallel pipeline, and without compromising the row-level security model defined inside Datasphere.

The problem Delta Sharing solves: end-customer landscapes increasingly run a multi-engine analytics stack. SAP Datasphere holds the governed business-semantic layer (analytic models, hierarchies, currency conversion), while the data-science teams work in Databricks or Fabric. Before Delta Sharing, the only options were nightly extracts (stale, expensive) or live federation (slow, governance-breaking). Delta Sharing publishes a Datasphere view as a Delta table that any Delta-Sharing-compatible client can read live, with SAP's row-level security still enforced at the producer side.

The protocol has two roles. The producer is a Datasphere space that publishes a share — a named collection of tables and views — with a recipient credential. The producer governs which columns are exposed, which row filters apply per recipient, and how often the underlying view is refreshed. The consumer reads the share using any Delta-Sharing client library: pandas, Spark, Databricks SQL, or Fabric notebook. The consumer never sees the underlying Datasphere connections or the source HANA tables — only the published surface. Authentication uses a bearer token tied to the recipient credential; revoking the credential immediately cuts access.

Why it matters

SAP's row-level security still applies at the producer side, so the consumer only ever sees the published surface, never the underlying HANA tables.
Access runs on a bearer token tied to the recipient credential — revoking it cuts access immediately, with no separate infrastructure change needed.
It's read-only by design: don't reach for it when the consumer needs write-back or the integration is high-frequency operational — use BDC native shares instead.

Key points

Open protocol — any Delta-Sharing-compatible client (Databricks, Fabric, Snowflake, pandas, Spark) can read; no SAP-specific driver required.
Producer-side governance — column selection, per-recipient row filters, refresh cadence, and credential lifecycle all controlled in Datasphere.
Row-level security carry-over — RLS rules defined in the Datasphere analytic model apply to the published share; recipient sees only its authorised rows.
Bearer-token authentication — recipient credential revocation cuts access in seconds; no key rotation, no shared secrets in code.
Read-only — for write-back scenarios, use BDC native shares or HANA replication instead.
Distinct from the packaged BDC Connect for Databricks (C166) / BDC Connect for Snowflake (C168) connectors, which use Delta Sharing or an equivalent as their underlying mechanism but add a supported commercial and SLA path.
One share per distinct authorisation scope, not one share with a widened filter for every recipient — the pattern that prevents silent over-exposure.
Best fit for an external, cross-platform-generic, read-only, ad hoc or exploratory integration; the wrong tool the moment write-back or a committed refresh SLA is required.

Terms used on this page

Delta Sharing: Open-source protocol (originated at Databricks, now a Linux Foundation project) for secure cross-platform data sharing without copying; any compatible client reads a published share over HTTPS using bearer-token auth.
Share: A named collection of Datasphere tables and views published to one or more recipients with column-selection and row-filter governance applied at the producer side.
Recipient credential: The bearer token bound to a specific external consumer; revocation in Datasphere immediately cuts the consumer's access without affecting other recipients.
Row-level security carry-over: The pattern where RLS rules defined in the Datasphere analytic model continue to apply to data exposed via Delta Sharing — the consumer cannot bypass them by reading the share directly.
Producer (Delta Sharing): The Datasphere space acting as the source of a share; it decides which columns are exposed, which row filters apply per recipient, and how often the underlying view refreshes.
Consumer (Delta Sharing): The external client — Databricks, Fabric, Snowflake, or a custom Python/Spark client — that reads a published share; it never sees the producer's underlying connections or source tables.
BDC native share: SAP's own governed sharing mechanism inside Business Data Cloud, distinct from open Delta Sharing, used when a scenario needs write-back, tighter SAP-side integration, or a higher-frequency operational refresh than a read-only Delta share provides.

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 →