SAP Datasphere data marketplace — the mechanism behind the word
As of 2026-08-14
Marketplace is a word that hides a mechanism. In the current SAP data stack, external data reaches a Datasphere or Business Data Cloud estate through an open sharing protocol and a governance contract, not through a shopping cart — and the useful question for anyone architecting this is not what is in a catalogue, but what a subscribed dataset costs, who governs it, and what happens when the publisher changes its schema.
The protocol underneath any data sharing in this stack
Delta Sharing is an open protocol for sharing tables in the Delta Lake format across organisations, tool stacks and cloud regions without copying the data. It began as a Databricks project and now sits under Linux Foundation governance, which is why adoption reaches beyond Databricks — Snowflake, Iceberg-based lakehouses and SAP all speak it.
A share has three layers. The share definition is a named, versioned bundle of tables the producer exposes. The recipient credential is a token-scoped URL issued to one named consumer, revocable independently of every other recipient. The data plane earns the zero-copy label: a consumer's query returns pre-signed URLs pointing at files in the producer's object store, and the consumer's own engine reads them.
The producer's compute is therefore never in the query path, which is why the pattern scales to many consumers without the producer provisioning capacity for each new subscriber.
Subscribing: where external data actually comes from
Inbound sharing lets a tenant subscribe to Delta tables published by an external organisation — through the Databricks Marketplace, AWS Data Exchange, or a direct partner share. Those tables appear as first-class catalog objects, usable from modelling and from notebooks, read in real time with no copy unless replication is explicitly configured.
Federating an Iceberg lake, pushing live query down to a Snowflake warehouse and subscribing to a partner share are all variations on one idea: the catalog is the single place a governed object is described, wherever the bytes live.
A representative enterprise estate in 2026 runs roughly seventy percent SAP-native data, twenty percent on an open-stack platform and ten percent received from partners. That last tenth is what a marketplace conversation is actually about, and it used to require a bespoke pipeline per partner.
Publishing: a share is a contract or it is a liability
The outbound direction is where governance stops being automatic. A published dataset should carry the five things that make it a product: a versioned schema, a stated commitment on freshness and completeness, an explicit roster of authorised consumers, a named owner, and lineage back to its sources.
With that in place, a breaking change follows announce, grace period, release, and the producer keeps the freedom to refactor underneath as long as the contract holds. Note the asymmetry: narrowing a schema or removing a column is a contract change; adding one usually is not.
Recipient credentials are the security surface — per-consumer and independently revocable, which only helps if they are rotated on a cadence, quarterly as a default and monthly in regulated industries.
What subscribing costs, honestly
Three cost lines, none of them on the platform invoice.
Egress: cross-region and cross-cloud reads are billed by the cloud provider. Ten terabytes shared to five partners has run in the region of two to five hundred US dollars a month — immaterial against the platform, material in a chargeback model that assumed zero.
Consumer-side compute: the reader's engine does the work, so a heavy analytical workload against a shared table generates charges nobody budgeted when zero-copy was pitched as a pure saving.
Latency: warm reads land in the one-to-five-second range and a cold cross-region first read is meaningfully slower. Fine for analysis, wrong for an operational dashboard — the same federate-or-replicate decision in a different costume, with our threshold around a hundred gigabytes per partner per month.
What we cannot assert
We hold no verified material on an SAP-operated, Datasphere-branded data marketplace as a storefront — no provider list, no catalogue size, no listing prices — so none appears here. What this page describes is the sharing and federation mechanism our corpus does cover. If SAP's own documentation for your release names a marketplace surface, that is the authority for what it contains.
Frequently asked
How does SAP Datasphere consume third-party data?
Through inbound Delta Sharing and federation: tables published by an external organisation — via the Databricks Marketplace, AWS Data Exchange or a direct partner share — appear as first-class catalog objects, read in place with no copy unless replication is configured.
Is data sharing really zero-copy?
No bytes are duplicated, which is what zero-copy means. It is not zero-cost: the reader's engine consumes compute on its own platform, and cross-region reads incur cloud egress charges.
Can we publish our own data to partners?
Yes, as an outbound share. Treat it as a contract rather than an export: versioned schema, stated freshness commitment, named owner and consumer roster, with per-recipient credentials rotated on a cadence.
When should we replicate a shared dataset instead?
When volume or query frequency makes repeated live reads expensive, or when latency matters. Our working threshold sits around a hundred gigabytes per partner per month.
What this page is built on
- Delta Sharing Protocol (C016)
- BDC Connect (C015)
- Data Products (C010)
- SAP Data Products — The 300+ Catalogue (target 500+ by Q2 2026) (C269)