Analytics Legends The knowledge platform for SAP Analytics
Guide

SAP Databricks integration, as an architect has to explain it

As of 2026-08-14

SAP Databricks integration means two different things, and treating them as one is the expensive mistake on this topic. The first is the Databricks-managed lakehouse that ships inside SAP Business Data Cloud, pre-provisioned and billed through SAP rather than negotiated as a separate contract. The second is BDC Connect for Databricks, generally available since 6 October 2025, which federates a workspace the customer already owns. Both run on the same open protocol, both are genuinely zero-copy, and only one changes who holds the Databricks agreement.

Two integrations, one protocol

In the packaged form the lakehouse is a BDC component: Delta-format storage governed through Unity Catalog, reachable from Spark notebooks, MLflow or DBSQL, inside SAP's billing and governance boundary. That arrangement moves the invoice, not the skill — somebody still runs Spark, Delta and Unity Catalog day to day.

In the federated form the customer keeps their own workspace and their own contract, and BDC Connect registers it as a source in the BDC catalogue, where Datasphere modelling and Joule grounding see the external tables as native objects. It talks to Unity Catalog's Delta Sharing endpoint directly: no SAP-specific driver, no custom connector to maintain.

So "we have SAP Databricks integration" tells you almost nothing. The first scoping question is which of the two is on the table, because they carry different contracts, different cost lines and different failure modes.

What zero-copy means at query time

Delta Sharing is the protocol on both sides — created by Databricks, open-sourced in 2021 under an Apache licence, now under Linux Foundation governance, which is why Snowflake and Iceberg-based platforms speak it too.

A share has three layers: a named, versioned bundle of tables; a token-scoped recipient credential, revocable independently of every other recipient; and a data plane where the consumer receives pre-signed URLs pointing at the producer's object-store files. The consumer's own engine reads those files, so the producer's compute is never in the query path — which is why the pattern scales to many subscribers without provisioning capacity for each one.

Two consequences matter commercially. The surface is multi-consumer rather than a Databricks-only pipe: the same governed output is readable by Power BI direct query and Tableau. And it is bidirectional — a notebook can write a churn score or a forecast back into a location SAP registers as a data product, closing the loop without an export step.

Decision table: which of three architectures

No data-engineering capacity, business-user modelling over SAP data. Datasphere alone. Not the lesser architecture — the right one whenever nobody on the project would use Spark if you handed it to them.

A mature Databricks practice already exists, and the new requirement is governed access to SAP business data. Federate through BDC Connect. Migrating that practice into SAP-native tooling costs more than connecting it.

One vendor, one bill, one catalogue, and an SAP-majority estate. The packaged bundle. The profile it assumes is roughly seventy to eighty per cent of analytics-relevant data already inside SAP; invert that ratio and you pay packaging to keep a minority native.

The row people forget: who owns the integration contract. Datasphere alone and the bundle both hand you a supported seam. Federation leaves you owning schema evolution across two platforms that can each write the same Delta tables — which needs a written agreement about who may change what, not just a working connection.

Governance does not travel for free

The strongest claim made for this integration is that row-level security defined in SAP's Data Access Controls is inherited on the Databricks read side rather than re-implemented. Correct as design intent, dangerous as assumption: a misconfigured share exposes more than the source model intended, silently. Test a restricted role from a notebook before go-live.

Inheritance also does not remove work on the other side. Unity Catalog permissions still need maintaining, and a data product published with weak lineage surfaces as an equally weak table. The workable split is SAP governing classification and field masking, Unity Catalog governing which team sees which shared table — written down before the first product is published, or two frameworks drift into contradicting each other.

One control gets forgotten routinely: share registration uses an OAuth 2.0 bearer token scoped per BDC tenant, and tokens expire. A share that stops refreshing looks exactly like a live connection.

The costs that survive the deleted pipeline

Zero-copy is not zero-cost. Every query against a shared Delta table consumes compute on the reading side, so a heavy analytical workload against a BDC-exposed data product generates Databricks charges the business case never modelled.

The same holds for every federated source in the other direction: federation shifts compute onto whichever platform serves the query — Snowflake credits, DBUs, object-store reads — and none of it appears in the capacity-unit conversation on the SAP side.

There is also a prerequisite that has stalled projects. Delta Sharing as a consumer requires Unity Catalog; a workspace still on the classic Hive metastore has to migrate first, moving table references, access policies and notebook code, and that has landed as a four-to-six week block dropped into a delivery plan. Confirm the metastore at initiation, not at configuration.

What this integration is not

It is not change data capture. A Databricks query reads BDC storage at query time, and freshness is governed by BDC's own refresh cadence — if the underlying dataset refreshes hourly, the share is hourly however zero-copy the path. Real-time detection needs SAP change data capture feeding Structured Streaming instead.

It is read-only in the direction of the share. A consumer can query the current version but cannot run time travel, MERGE or OPTIMIZE against it; those belong to the producing side. Needing history or write access means caching the table into your own Delta Lake, which reintroduces the copy the architecture was chosen to avoid.

And it is not a substitute for data modelling. Because no data moves, teams assume no governance work is needed. What happens instead is that governance relocates to the boundary, where it has to be enforced in both directions.

What we cannot assert

SAP publishes no rate for the Databricks capacity embedded in Business Data Cloud, so we cannot say what the packaged lakehouse costs against a direct Databricks agreement — only that the two are different contracts. Roadmap items for further partner endpoints are commitments SAP can re-time, not delivery dates.

Frequently asked

Does BDC Connect for Databricks copy SAP data?

No. Reads flow from BDC-managed storage to the Databricks cluster through Delta Sharing, using pre-signed URLs against the producer's object store. There is no staging area and no second copy to keep in sync — which is also why freshness is bounded by the producing side's own refresh cadence.

Do I need Unity Catalog to consume an SAP data product?

Yes. Delta Sharing as a consumer requires Unity Catalog, so a workspace still on the classic Hive metastore has to migrate first. Scope that as a prerequisite workstream — it moves table references, access policies and notebook code, and has blocked delivery plans for four to six weeks when found late.

If I buy BDC, do I still need Databricks skills?

Yes. The packaged lakehouse changes who bills for the infrastructure, not who operates the workloads on it. Spark, Delta and Unity Catalog still need someone working with them daily, and a team that adopts the bundle without that person has bought a component it cannot run.

Can Databricks write results back into SAP?

Yes — the protocol is bidirectional. A Databricks-managed Delta table such as a model score or forecast can be registered as an external data product inside BDC and consumed from SAP Analytics Cloud through a live connection, with the data staying in Databricks-managed storage.

What this page is built on

Read next