SAP and Databricks: How the BDC Integration Works

The Short Answer

SAP and Databricks are no longer a DIY integration project — SAP Business Data Cloud (BDC) embeds Databricks natively as SAP Databricks, giving data teams lakehouse-grade engineering, machine learning, and AI capabilities directly on governed SAP data. That single fact changes how you should plan any architecture that involves SAP data and a lakehouse. Instead of extracting tables out of S/4HANA or BW with third-party ETL and rebuilding business logic on the other side, you can now work with SAP data products that keep their semantics, lineage, and access controls intact — either inside BDC itself or shared, zero-copy, with an external Databricks workspace via Delta Sharing.

This guide is the practical version of that story for data and IT leaders: what the old integration pattern cost you, what the SAP-Databricks partnership actually delivers, how to choose between the embedded and bring-your-own models, and where the honest limitations are. It is the third part of our Business Data Cloud series — for the platform overview see our SAP Business Data Cloud guide, and for the AI angle see why BDC is the AI-ready data foundation.

The Old World: Extracting SAP Data Into a Lakehouse

For years, getting SAP data into Databricks (or any lakehouse) meant building and babysitting extraction pipelines: a third-party ETL or CDC tool pulling from S/4HANA or ECC via ODP extractors, log capture, or OData, landing raw tables in object storage, followed by layers of transformation notebooks that tried to reconstruct what the data actually meant.

This pattern worked, in the sense that data moved. But every team that ran it at scale hit the same four problems:

• Lost business context. SAP data is not just tables — it is business objects with relationships, hierarchies, currency and unit-of-measure logic. A raw extract of ACDOCA rows tells a data scientist very little without weeks of reverse-engineering. The semantics lived in SAP; the data lived in the lake; the two never met.
• Pipeline sprawl. Each new use case spawned another extract, another schedule, another schema-drift incident when an SAP upgrade changed a structure. Integration teams spent their time on plumbing maintenance rather than new value.
• Governance debt. Once data left SAP, its access controls and lineage left with it. Answering "who can see this, and where did it come from?" across the extracted copies became an audit problem.
• Reconciliation pain. Finance never fully trusted lakehouse numbers, because the extracts diverged from what the SAP application logic reported. Every executive dashboard came with an asterisk.

None of this was Databricks' fault, or SAP's individually. It was the inevitable cost of treating two governed platforms as endpoints of a hand-built pipe.

What Changed: SAP Databricks Inside Business Data Cloud

The SAP-Databricks partnership, announced as part of the Business Data Cloud launch, restructures this relationship. Two things are new, and it is worth being precise about both.

First, SAP Databricks is a native component of BDC. This is Databricks capability — notebooks, data engineering, machine learning, AI tooling — provisioned and operated as part of the SAP Business Data Cloud offering, not a separate platform you wire up yourself. It sits inside SAP's commercial and governance boundary. You buy BDC, and lakehouse-grade data science on SAP data comes with it.

Second, the data access model is sharing, not copying. BDC exposes SAP data as curated, governed data products — semantically rich, business-ready datasets built from S/4HANA, SuccessFactors, and other SAP sources. SAP Databricks accesses these through zero-copy sharing based on the open Delta Sharing protocol, so the engineering and ML workloads read governed SAP data without a replication pipeline in between. The same mechanism works in the other direction: insights and features produced in Databricks can flow back into the BDC semantic layer for consumption by analytics and SAP's AI stack.

As of recent announcements, the partnership positions this as bidirectional and open — the same Delta Sharing foundation also connects BDC to external, customer-managed Databricks workspaces (more on that choice below). The specifics of which SAP data products are available, in which regions, under which editions are still evolving, so treat any detailed capability matrix you read — including vendor slides — as a snapshot to verify, not a commitment.

The strategic point stands regardless of the fine print: the integration burden has moved from your team to the platform. The problem the old ETL stack tried to solve — SAP data, with meaning, available to lakehouse tooling — is now a product feature rather than a project.

What You Can Actually Do With It

Capabilities matter less than use cases. Three patterns account for most of the early interest we see.

Machine Learning on SAP Data Without Pipeline Sprawl

The classic examples — demand forecasting on sales orders, payment-behavior prediction on receivables, supply-risk scoring on procurement data — historically stalled on data acquisition, not modeling. With SAP Databricks reading governed data products directly, a data science team starts from business-ready entities instead of raw table dumps, and the majority of project time that used to go to data preparation shrinks because that work was done once, centrally, in the semantic layer.

Blending SAP and Non-SAP Data

Databricks is often where an organization's non-SAP data already lives: clickstream, IoT telemetry, market data, CRM extracts. The integration lets you join governed SAP data products with that estate — customer profitability combining S/4HANA margins with web behavior, maintenance predictions combining SAP asset master data with sensor streams — without first flattening the SAP side into meaning-free CSVs.

Feeding AI and Agents With Governed Features

SAP's AI strategy — Joule, agents, Business AI — grounds itself in BDC's governed layer, as we covered in the AI foundation post. SAP Databricks extends that loop: features and predictions engineered in Databricks can be published back as governed data products, so an agent making a decision draws on ML outputs that carry the same lineage and access control as the source data. That closed loop — governed data in, governed intelligence out — is the architecture regulators and auditors will actually accept. If AI is the driver, sequence the work with a deliberate SAP AI adoption strategy rather than letting the tooling lead.

Native SAP Databricks vs Your Own Databricks: The Decision

Most organizations evaluating this already run Databricks somewhere. So the real question is rarely "Databricks or not" — it is embedded SAP Databricks inside BDC, an external Databricks workspace connected via Delta Sharing, or both. Here is how the three approaches compare, including the legacy pattern as the baseline:

The decision factors that actually settle it:

• Where is your center of gravity? If your data science organization, feature stores, and MLOps discipline already live in a corporate Databricks environment on Unity Catalog, sharing governed SAP data products into that estate preserves your investment and your operating model. If you have no meaningful lakehouse footprint and the dominant data is SAP, the embedded option gets you to value without standing up a new platform.
• Who must govern what? The embedded model keeps everything inside one SAP-governed boundary — attractive for regulated industries and for CIOs consolidating vendor surface area. The external model gives your platform team control but makes governance a shared responsibility you must design deliberately.
• Cost model. SAP Databricks is part of BDC's consumption-based commercial model; an external workspace runs on your existing Databricks agreement. Which is cheaper depends entirely on your workloads and contracts — model both, and do not trust anyone's generic numbers, including ours. We deliberately quote no prices here because they vary by agreement and change frequently.
• Both is a valid answer. A common enterprise pattern: embedded SAP Databricks for SAP-domain data products and finance-adjacent ML, external Databricks for the broader engineering estate, with Delta Sharing keeping the two consistent instead of duplicating data.

Architecture Patterns That Hold Up

Whichever deployment you choose, two principles separate durable architectures from expensive rework.

Keep the semantics in the BDC layer. The whole value of this integration is that SAP data arrives with its business meaning attached. Resist the temptation to treat BDC as just another source to strip-mine: consume the curated data products, and when you need new entities, push that modeling work into the semantic layer where every consumer — Databricks, SAP Analytics Cloud, Joule — benefits from it once.

Do not re-extract what is already shared. If teams start copying shared data products into private schemas "for performance" or convenience, you have rebuilt the pipeline sprawl and reconciliation problem with newer tools. Zero-copy sharing is the mechanism *and* the discipline: enforce it with platform guardrails, not memos.

Get these two right and the rest — workspace topology, catalog structure, CI/CD for notebooks — is normal lakehouse engineering.

What This Means for BW Customers

If you run SAP BW or BW/4HANA, this partnership sharpens a decision you already face. BW's historic value was curated, semantically consistent SAP data for analytics — and that is precisely what BDC data products now provide, with a lakehouse attached. For many BW workloads, the destination is no longer "another warehouse" but the BDC layer, with Databricks handling the heavy engineering and data science that BW was never built for.

That does not make BW exits automatic. The comparison of platforms, migration paths, and the SAP BW bridge is covered in depth in our Datasphere vs BW/4HANA analysis, and the practical takeaway carries over: understand what in your BW estate deserves to survive before choosing its destination. If you are scoping that exit, our BW/4HANA migration practice runs assessments that account for the BDC-plus-Databricks end state rather than migrating you to another dead end.

Honest Limitations

An authoritative recommendation requires naming what is not yet proven.

• Maturity. SAP Databricks inside BDC is a young offering. Expect the feature surface to lag standalone Databricks in places, and expect rough edges in provisioning, identity integration, and tooling parity. Pilot before you commit a flagship program.
• Regional and edition availability. Rollout is phased. Which hyperscaler regions, which BDC editions, and which SAP source systems are supported changes quarter to quarter — verify current availability with SAP for your specific landscape before planning dates around it.
• Data product coverage. The value depends on SAP shipping (and you activating) data products that match your processes. Coverage is growing but not exhaustive; gaps mean custom modeling work in the semantic layer.
• Skills. This architecture asks SAP teams to learn lakehouse concepts and lakehouse teams to respect SAP semantics. Underestimating that convergence is the most common non-technical failure mode we see.
• Commercial clarity. Consumption models are flexible but hard to forecast. Insist on a sizing exercise with real workload assumptions before signing.

None of these are reasons to wait indefinitely — they are reasons to start with a bounded pilot and verify claims against your own landscape.

Getting Started

A pragmatic sequence, drawn from how we run these engagements:

1. Inventory the current state. Catalog every existing SAP-to-lakehouse pipeline, its consumers, and its maintenance cost. This is your business case baseline.
2. Confirm availability and fit. Verify with SAP that BDC and SAP Databricks are available in your region and cover the data products your first use case needs.
3. Pick one use case with a paying customer. One ML or blended-analytics scenario with a named business owner beats a platform-first rollout every time.
4. Decide embedded vs external deliberately. Use the decision factors above; document the choice and the governance split it implies.
5. Deliver, measure, retire. Ship the use case, measure it against the old pipeline's cost and trust level, and retire the legacy extract it replaces. Every retired pipeline funds the next use case.

After 15+ years of SAP infrastructure work and 100+ engagements, our strong opinion is that the SAP-Databricks integration is the most consequential change to SAP data architecture since HANA — not because of any single feature, but because it ends the era where SAP data had to lose its meaning to become useful elsewhere. If you want help assessing fit, choosing the deployment model, or planning the pilot, our SAP Business Data Cloud services team does exactly this work.