The Essentials
SAP data reaches the Databricks lakehouse three ways: SAP Databricks running inside SAP Business Data Cloud, SAP Business Data Cloud Connect sharing data products into your existing Databricks workspace over Delta Sharing with no copy, or classic extraction and replication. Business Data Cloud wins on semantics and effort; extraction wins on coverage and control.
- Cost: the sharing paths require SAP Business Data Cloud; extraction requires a replication tool or engineering time plus storage.
- Effort: sharing a published data product is configuration; extraction of custom tables is a project.
- Risk: SAP is not a Lakeflow Connect managed connector, so do not plan around one.
- Fit: shops already buying Business Data Cloud should share first and extract only the gaps.
SAP is the source every enterprise data team dreads. Tables carry four-character German abbreviations, business meaning lives in application logic rather than the schema, and one sales order touches a dozen tables. It is no surprise that a Fivetran benchmark of 500 senior data leaders found 53% of engineering capacity going to pipeline maintenance rather than new capability.
The options changed on 13 February 2025, when Databricks and SAP announced SAP Databricks inside the new SAP Business Data Cloud, with bi-directional sharing over Delta Sharing and governance in Unity Catalog. A second route followed on 6 October 2025, when SAP Business Data Cloud Connect for Databricks reached general availability for existing Databricks customers.
So the question for a mid-market or enterprise SAP shop is no longer “how do we extract SAP?” It is which of three paths fits, which data each one actually covers, and what breaks when the business process behind the data is still inconsistent. This comparison answers those in order.
The Three Paths, Side by Side
| Path | Where the work runs | Copies data? | What you get | Main dependency | Best for |
|---|---|---|---|---|---|
| SAP Databricks in Business Data Cloud | A Databricks environment inside SAP BDC | No, shares data products | Notebooks, SQL editor, Unity Catalog on SAP data products | SAP BDC, bought through SAP | SAP-centric teams starting fresh |
| BDC Connect to your own workspace | Your existing Databricks lakehouse | No, live zero-copy share | SAP data products mounted in Unity Catalog | SAP BDC plus a Unity Catalog workspace | Teams with an established lakehouse |
| Extraction and replication | Your pipelines and a replication tool | Yes, raw tables land in bronze | Any table you are licensed to extract | Engineering time and SAP interface licensing | Custom tables, older releases, full history |
Path One: SAP Databricks Inside Business Data Cloud
SAP Business Data Cloud is SAP’s data layer, and SAP Databricks is the Databricks Data + AI Platform running natively within it. Databricks announced it generally available on 30 April 2025, with notebooks, the SQL editor, Unity Catalog and support for machine learning, and SAP customers get started through their SAP account teams.
The appeal is semantics. You work on SAP-published data products rather than raw tables, so the business meaning SAP already encodes arrives with the data. The trade-off is that this environment sits inside SAP’s commercial wrapper. If your organisation already runs a Databricks lakehouse for non-SAP data, you now have two environments to govern, linked by Delta Sharing.
Path Two: Business Data Cloud Connect to an Existing Workspace
For teams that already run Databricks, BDC Connect is usually the cleaner answer. Databricks describes it as zero-copy, bi-directional, live sharing of SAP data products, which mount directly into Unity Catalog and behave like any other Delta-shared asset. The GA announcement names data from SAP ERP alongside SAP Ariba, SuccessFactors, Concur and Fieldglass.
Mechanically, this changes where the work sits. There is no bronze copy of the SAP table to maintain, no nightly extract to babysit, and no second governance model: grants, lineage and tags live in the same Unity Catalog as your NetSuite, CRM and web data. Your engineers start at the equivalent of silver, joining SAP data products to everything else and building gold views for Power BI or an AI agent.
The limit is coverage. You get what SAP publishes as data products. Heavily customised tables, Z-fields your finance team depends on, or history from an older release do not appear just because the connector is live. Map your reporting requirements against the published data products before you retire any extraction job.
Path Three: Extraction Still Has a Job
Extraction is the old path: a replication tool or custom job reads SAP tables or extractors, lands them raw in bronze, and your pipelines rebuild the business logic in silver. It is heavier, and it copies data, but it reaches places the sharing paths do not. For deep background on sequencing that kind of move, our guide to warehouse to lakehouse migration covers the cutover pattern.
One correction worth making early, because it shows up in vendor decks and forum threads alike: SAP is not one of the managed connectors in Lakeflow Connect. Lakeflow Connect covers sources such as Salesforce, Workday and SQL Server. The documented Databricks route for SAP is the Business Data Cloud integration. If you extract, you bring your own replication tool or code, and you land the result with Auto Loader or a pipeline you run.
Once raw SAP data is in bronze, the lakehouse mechanics are familiar. AUTO CDC with SEQUENCE BY applies inserts, updates and deletes in the right order when change records arrive late. Expectations catch broken keys before they reach silver. Unity Catalog governs the result the same way it governs a shared data product, so a hybrid of paths two and three stays under one set of controls.
What Goes Wrong When SAP Data Moves
- Semantics get rebuilt, badly. Extraction lands table fields, not business meaning. Teams rewrite pricing, currency and status logic that SAP already applies, and the lakehouse number disagrees with the SAP report by a rounding rule nobody documented.
- Two masters disagree. Customer and material masters drift between plants or company codes. Joining them to CRM or ecommerce data multiplies the drift, and the lakehouse gets blamed for a source problem.
- Near-real-time gets expensive. Practitioners on the Databricks community report that change capture on busy transactional SAP tables gets heavier as refresh frequency rises. Decide which tables truly need minutes and let the rest run daily.
- Licensing is assumed, not checked. Extraction interfaces and third-party access to SAP carry contractual terms. Confirm what your agreement allows before you design around a particular interface.
- Coverage gaps surface late. A BDC Connect rollout looks finished until month-end close needs a custom field that is not in any data product. Inventory required fields first, then decide share or extract per field.
Red Flags That Say Fix the Process Before You Connect SAP
Every one of the problems above is a process problem that data engineering exposes. Connecting SAP to a lakehouse faster does not fix them; it spreads them. We start every SAP engagement with the Assess step of AIM-IT, and these are the signals that stop the build until the process is fixed.
- Finance and operations report different revenue for the same month. Agree the definition, and the SAP source of truth for it, before you model a single gold table.
- Nobody owns the customer or material master. Without a named owner and a correction workflow in SAP, every duplicate you catch in silver comes back next week.
- Custom Z-tables have no documentation. If the people who built them have left, extraction will copy logic nobody can explain. Document or retire them first.
- Every report is “urgent real-time”. When the business cannot say which decisions need minutes, you will pay streaming costs for monthly reports.
- The plan is to extract everything. Wholesale replication with no reporting requirement behind it is a storage bill, not a strategy. Share what SAP publishes, extract only the proven gaps.
Our data engineering consulting work covers SAP, NetSuite and SaaS sources conformed into one governed layer. If you want an independent view of which path fits your SAP estate, start with our Databricks consulting assessment.
Frequently Asked Questions (FAQs)
What is SAP Databricks?
SAP Databricks is the Databricks Data + AI Platform running natively inside SAP Business Data Cloud, announced in February 2025. It gives SAP customers notebooks, a SQL editor and Unity Catalog governance on SAP data products, and it is obtained through SAP.
Can I connect SAP to my existing Databricks workspace?
Yes. SAP Business Data Cloud Connect for Databricks, generally available since October 2025, shares SAP data products live and without copying into an existing Unity Catalog workspace over Delta Sharing. You need SAP Business Data Cloud in place for it.
Is SAP a Lakeflow Connect connector?
No. Lakeflow Connect managed connectors cover sources such as Salesforce, Workday and SQL Server, but SAP is not among them. The Databricks route for SAP is the Business Data Cloud integration; otherwise you use your own replication tool or code.
Can I get SAP data into Databricks in near-real-time?
The Business Data Cloud sharing paths are live shares, so there is no extract schedule to wait on. With extraction, near-real-time change capture is possible but costs more as frequency rises on busy tables, so reserve it for the tables that drive time-sensitive decisions.
Do I still need data engineering if SAP shares data products?
Yes, less at the bottom and just as much at the top. Sharing removes the raw extract, but you still join SAP data to other sources, apply quality checks, handle fields that are not in any data product and build the gold views people actually use.