SAP Databricks or Your Own Databricks? Choosing the Compute Layer in BDC

SAP Databricks has been part of SAP Business Data Cloud since spring 2025, starting on AWS. Since then we hear the same question in almost every data conversation: “We already have Databricks. Do we now pay twice?” Or the reverse: “We have no Databricks. Do we need it now?”

Both are fair questions. This post lays out the three realistic options and the criteria we use to choose between them.

TL;DR: You have three options. Use SAP Databricks inside BDC when you start fresh and want one contract with SAP. Keep your own Databricks and connect it through zero-copy Delta Sharing when you already run it productively. Stay with Datasphere and SAP Analytics Cloud only when your use cases are reporting and planning. Most Swiss mid-market companies belong in the third group today.

What is actually on the table

SAP announced Business Data Cloud in February 2025 together with a Databricks partnership. Our BDC timeline 2025 to 2026 covers everything SAP announced since. Two things came out of that partnership.

SAP Databricks. A Databricks environment sold by SAP as a component of BDC. It reads SAP data products through Delta Sharing, without copying them into another store. It brings notebooks, machine learning tooling and Unity Catalog for governance. It started on AWS; check which hyperscaler and region your BDC tenant runs on before you plan.

Sharing with your own Databricks. Bi-directional, zero-copy Delta Sharing between BDC and customer-owned Databricks environments now has a product name, SAP BDC Connect for Databricks, which SAP listed as available in October 2025. The idea: SAP data products appear in your existing workspace, and results can flow back, without a replication pipeline in between.

The third option is easy to forget: no Databricks at all. Datasphere for modelling, SAP Analytics Cloud for dashboards and planning. That is how BDC works for many companies, and it is a complete setup.

Option 1: SAP Databricks inside BDC

This fits companies that start without a data science platform but have concrete machine learning plans. Examples: demand forecasting on S/4HANA sales history, churn scoring on service data, price elasticity.

What speaks for it:

• One contract and one vendor for the data layer.
• Data products arrive by zero-copy sharing, so nobody builds extraction jobs.
• Governance sits in one catalogue next to the SAP semantics.

What to check:

• Hyperscaler and region availability for your BDC tenant.
• How consumption is billed and how you will see it per use case.
• Whether non-SAP sources you need can be brought in with reasonable effort.

Option 2: your own Databricks, connected by Delta Sharing

This fits companies that already run Databricks productively. Typical signs: a data team with pipelines, models in production, and non-SAP sources (web shop, IoT, marketing platforms) already landed there.

Moving all of that into SAP Databricks rarely makes sense. Better: let SAP data products flow into the existing workspace through Delta Sharing, and keep the team where it already works.

What to check:

• Which data products you actually need, and whether they exist for your release.
• Who owns access rights. Two catalogues (Unity Catalog on your side, BDC on SAP’s side) need one clear governance model.
• The availability of BDC Connect for your hyperscaler and region. Confirm it for your tenant before you commit.

Zero-copy is the point. If someone proposes to replicate SAP data into your Databricks “for now”, ask why. Replication brings back exactly the pipeline maintenance that BDC is supposed to remove.

Option 3: Datasphere and SAP Analytics Cloud only

This is the right answer more often than vendors like to admit. If your questions are “Why does the pipeline report disagree with revenue?” or “How do service margins develop per customer segment?”, you need clean, joined, well-modelled data. You do not need a notebook.

Datasphere covers modelling and federation. SAP Analytics Cloud covers dashboards and planning. Intelligent applications, which SAP introduced at Sapphire 2025, sit on the same data products. Our BDC timeline tracks which of them are generally available.

You can add a Databricks layer later. Data products do not change because you add a consumer.

Five criteria for the decision

1. Use cases. Write down the three questions you want answered in the next twelve months. If none of them needs a trained model, option 3 is enough. If one does, look at options 1 or 2.

2. Skills. Databricks needs people who write Python or SQL in notebooks and run models in production. Many Swiss mid-market companies have one or two analysts and no data engineers. A platform without the people to run it is shelfware.

3. Existing investment. A productive Databricks with real pipelines is an argument for option 2. A trial workspace somebody opened two years ago is not.

4. Governance. Decide who grants access to customer and financial data. Under the revised Swiss FADP (nDSG), you must be able to say where personal data sits and who can read it. One catalogue is easier to explain to an auditor than two.

5. Cost transparency. Ask for consumption to be visible per use case, not per platform. With two platforms you get two invoices that each look reasonable. Only together do they show what your forecast model really costs.

What this means for you

For most of our clients on SAP Sales Cloud V2, Service Cloud V2 and S/4HANA Public Cloud, the first BDC use case is analytical: one view of pipeline, orders and service across ERP and CRM. That runs on Datasphere and SAP Analytics Cloud.

There is a CX detail to know. SAP’s data products started with S/4HANA, Ariba and SuccessFactors. Where no data product exists for your release, CX data from Sales Cloud V2 and Service Cloud V2 needs a custom route into Datasphere, for example events via SAP Integration Suite or replication. That work is the same whichever compute option you choose.

So our practical advice:

• Start with Datasphere and SAP Analytics Cloud and one management question.
• Keep your existing Databricks if you have one, and connect it with BDC Connect instead of a replication pipeline.
• Add SAP Databricks when a concrete machine learning case has an owner, a budget and someone to run it.

Next step

If you are unsure which group you belong to, we can sort it out in a short session with your use cases on the table. See our Business Data Cloud services for how we approach the first step.

FAQ

Is SAP Databricks the same as a normal Databricks workspace?

It runs on Databricks technology, but SAP sells and operates it as a component of Business Data Cloud. It is built to work on SAP data products through Delta Sharing without copying. A Databricks workspace you contract directly is a separate platform with its own contract, billing and administration.

Can we keep our existing Databricks and still use BDC?

Yes. SAP BDC Connect for Databricks shares data products bi-directionally and zero-copy with a Databricks environment you contract yourself; SAP listed it as available in October 2025. That is the intended path if you already run Databricks. Check availability for your hyperscaler and region before you plan around it.

Do we need Databricks at all for reporting?

No. Datasphere models the data and SAP Analytics Cloud shows it. Databricks adds value for data engineering at scale, machine learning and data science. If your use cases are management reporting and planning, you can start without any Databricks layer.

Which hyperscalers support SAP Databricks?

SAP Databricks started on AWS in spring 2025, and SAP extended BDC to further hyperscalers afterwards; since March 2026 BDC runs on Microsoft Azure in Switzerland. Which BDC components are offered in which region changes, so confirm it for your tenant. For Swiss companies with data residency requirements, the region matters as much as the hyperscaler.