31. October 2026 · AI
Setting Up SAP Databricks: What It Is, How to Start, Where the Limits Are
Not a connector, not a database, not just a data lake. A practical guide from provisioning to reporting, with an honest section on harmonizing several ERP systems.
The SAP Business Data Cloud contract is signed, SAP Databricks is part of the offer, and in the first architecture workshop someone asks: “So is this a connector, a database or a data lake?” The honest answer: none of them on its own. And that ambiguity decides whether the team delivers results in three months or is still debating who owns storage, permissions and cost. This guide explains what SAP Databricks is, walks through setup, and shows where the limits are, especially when SAP is not the only ERP in the landscape.
Status of this article: 31 October 2026. It is based on the official SAP Databricks documentation, with page versions dated 11 September to 29 October 2026. The product is generally available; some features (such as serverless usage policies) are still in Preview according to the documentation. Scope and navigation paths change, so check the linked sources before you implement. I describe the SAP-side steps only as far as the Databricks documentation records them; the SAP help pages could not be retrieved for machine verification.
The goal: After reading this, you can decide whether SAP Databricks fits your initiative, set up an account cleanly, connect SAP and non-SAP data, and move results into reporting and back into SAP in a controlled way.
What SAP Databricks actually is
The documentation puts it briefly: SAP Databricks is “a version of Databricks available as an application in SAP Business Data Cloud (BDC)”. To understand what that means, look at Databricks itself. Databricks describes itself as a unified, open analytics platform built on Apache Spark and two further core technologies: Delta Lake, a storage layer with ACID transactions and schema enforcement, and Unity Catalog, a governance layer for data and AI. The architecture pattern behind it is the lakehouse: a data management system that combines the properties of a data lake and a data warehouse.
That answers the workshop question:
| Term | Does it apply? | Why |
|---|---|---|
| Connector | No | SAP Databricks does not copy data from A to B. According to the documentation, SAP data products appear as a catalog in the workspace “without replication”. The link is a sharing protocol (OpenSharing), not a load process. |
| Database | Partly | You can create, query and write tables. But compute (serverless SQL warehouses, serverless compute for notebooks) and storage are separate, and storage is managed by SAP. |
| Data lake | Partly | There are volumes for non-tabular data and tables on object storage. Unlike a plain data lake, transactions, schema checks and central permissions sit on top. |
| Workspace for analytics and AI | Yes | Notebooks (Python and SQL), SQL editor, visualizations, machine learning, model serving, vector search. This is the actual core. |
The one-line version: SAP Databricks is a managed compute and governance environment that reads SAP data products without copying them and can hand its own results back as new data products.
Compared with standalone Databricks, there are differences you should know. The SAP edition calls itself a “special edition of Databricks optimized for analytics and AI for data in SAP”. Notebooks support Python and SQL; general Databricks also lists R and Scala. All workspaces are serverless, with storage and compute managed for you. And data exchange is asymmetric: SAP Databricks can receive OpenSharing shares but, according to the documentation, cannot initiate shares to destinations outside SAP.
Do you need it at all?
SAP Databricks is worth it when at least three of these apply:
- You have licensed SAP Business Data Cloud or plan to. Without BDC there is no SAP Databricks.
- Your questions go beyond standard reports: forecasting, machine learning, enrichment with non-SAP data, AI functions on business data.
- You want to use SAP data without building and operating your own extraction pipelines.
- You have, or will have, people who work in SQL and Python. SAP Databricks is not a point-and-click tool for business users.
- Results should flow back into the SAP world, for example as a data product for other BDC applications.
If all you need is standard reporting on SAP data, SAP Databricks is probably the more expensive answer to a simpler question. If your focus is non-SAP data and SAP is one source among many, read the limitations below with particular care.
Prerequisites
- You have an SAP Business Data Cloud subscription. (Costs money and a contract decision.)
- You have someone with BDC admin rights who is allowed to provision SAP Databricks from the “SAP for Me” portal.
- You have decided who becomes the first account admin. That person receives the invitation after provisioning and holds the highest rights in the account.
- You use SAP Cloud Identity Services or plan to. SAP Databricks works with single sign-on only; according to the documentation, passwords are not supported.
- You have decided which cloud region the account will run in (more on that below; it is a one-way door).
- For non-SAP data: you have access to a storage bucket in the same cloud (S3, Azure Data Lake Storage or Google Cloud Storage) and the rights to create credentials there.
- For reporting: you have Power BI Desktop or the Power BI service, if that is where you report.
The map: which route, and why
| Route | When it makes sense | What speaks against it |
|---|---|---|
| SAP Databricks in BDC (the subject of this article) | SAP data is the focus, you want to work without replication and hand results back to SAP | Narrower feature set than general Databricks, no shares to the outside, storage under SAP’s control |
| Standalone Databricks | Many non-SAP sources, your own cloud storage, full choice of languages and tools | How a standalone workspace gets access to BDC data products is not described in the sources read here. Clarify that with SAP and Databricks before you choose this route. |
| No Databricks | Pure standard reporting on SAP data | Once forecasting, ML or enrichment are added, you end up building it later anyway |
This article takes the first route, because it is the one most SAP customers with a BDC license evaluate first.
Step by step
Step 1: Provision the account from “SAP for Me”
What you do: A BDC admin provisions SAP Databricks in the “SAP for Me” portal following the SAP documentation. The flow then leads into the Databricks sign-up, where the first person verifies their email address and accepts the terms.
How you know it worked: The first invited person receives an email once the account is ready. The first workspace is created automatically.
Most common cause of failure: The wrong person gets invited first. According to the documentation, the first user automatically becomes account admin. Decide this beforehand, not at the moment of provisioning.
Step 2: Settle the region before you create more workspaces
What you do: Check which region the account is in and decide whether that meets your requirements. For Europe, the documentation lists Frankfurt (AWS eu-central-1 and GCP europe-west3) and West Europe in the Netherlands (Azure westeurope).
How you know it worked: The region is documented and signed off by data protection and IT security.
Most common cause of failure: Assuming you can add a second region later. The documentation is unambiguous: “Accounts can only deploy workspaces in a single region.” This is the point of no return in this guide. Also note that some features are regionally restricted; Foundation Model Fine-tuning, for example, requires the us-east-1 region according to the documentation.
Step 3: Connect identities and groups
What you do: Enable the integration with SAP Cloud Identity Services, Identity Provisioning. Users and groups are synchronized via SCIM. Databricks recommends using Cloud Identity Services as the single source of truth for identities across the SAP landscape and assigning rights through account-level groups, not to individuals.
How you know it worked: Users sign in at login.databricks.com with their SSO credentials, and the groups from the identity provider appear in the account.
Most common cause of failure: Groups are additionally maintained by hand in Databricks. According to the documentation, externally synchronized groups cannot be changed in Databricks by default; maintaining them twice leads to permissions nobody can explain.
Step 4: Secure the network without cutting the BDC connection
What you do: Decide whether you need IP access lists (access only from specific networks), serverless egress control (limits on outbound connections) or a network connectivity configuration (access to sources on your network, AWS and Azure only).
How you know it worked: The settings are active, and SAP data products can still be queried afterwards.
Most common cause of failure: IP lists or egress rules that break the connection to BDC. The documentation warns explicitly about this in both places and points to the SAP documentation first. Test every network change in a non-production workspace.
Step 5: Decide on access by support personnel
What you do: In the workspace settings (Settings, Advanced, Access Control), decide whether and for how long SAP Databricks personnel may access the workspace to investigate issues. According to the documentation, the options are up to 48 hours, permanent access, or no access.
How you know it worked: The setting is deliberately chosen and documented, not left at its default.
Most common cause of failure: Permanent access switched on for convenience. In regulated environments, time-limited access per support case is the defensible option.
Step 6: Cut workspaces by environment or team
What you do: In the account console (Workspaces, Create workspace), create additional workspaces, for example for development, test and production, and assign rights on the Permissions tab. Choose between separating by environment and separating by team. Rule of thumb: separate by environment as soon as production results are written back to SAP; separate by team when teams work with data of different sensitivity.
How you know it worked: Each workspace has a documented purpose and an accountable group.
Most common cause of failure: The automatically created first workspace quietly becomes production. Each workspace comes with its own workspace catalog, and according to the documentation all workspace users can create objects in its “default” schema. Without deliberate separation, that turns into an unstructured mix.
Step 7: Share SAP data products and narrow permissions
What you do: Request access to the data product you need in the BDC catalog and, once approved, share it to SAP Databricks (the SAP-side steps are in the SAP documentation). The data product then appears in Unity Catalog as its own catalog.
Then comes the step that is often forgotten: according to the documentation, all users in a workspace have read access to shared SAP schemas and tables by default. Narrow that through Unity Catalog’s privilege model to the groups that actually need the data.
How you know it worked: A query such as SELECT * FROM <catalog>.<schema>.<table> returns data in the SQL editor, and DESCRIBE TABLE EXTENDED shows the column descriptions and keys taken over from SAP.
Most common cause of failure: Personal data is readable by everyone because the default rights were never changed. SAP Databricks takes over SAP’s classifications for personal and sensitive data as tags in the sap.PersonalData namespace. Use these tags in attribute-based access control (ABAC) policies instead of locking table after table by hand. Do not change the tags yourself; the documentation warns that manually set values in the sap.* namespace may be removed again.
Step 8: Connect non-SAP data
What you do: The documentation lists three routes for non-SAP data: cloud storage buckets via external locations, external APIs, and received OpenSharing shares. For the most common case, files in a bucket, create an external location in Catalog Explorer under External data. On AWS there is a CloudFormation quickstart that also creates the required credentials.
How you know it worked: The external location is visible in Unity Catalog, and you can create external tables or volumes on it and grant rights.
Most common cause of failure: Expecting to write results straight back into your own bucket. The documentation requires external locations and storage credentials to be read-only so that SAP data stays in SAP-managed storage. The documentation is not consistent here, though: the S3 page says only AWS accounts can connect S3 buckets “with read and write access” and, in the same section, warns that external locations must be read-only. Plan for read-only access until SAP confirms otherwise in writing.
Step 9: Set up compute, cost control and reporting
What you do: Workspace admins create serverless SQL warehouses; users need at least CAN USE permission to run queries on them. At the same time, set up cost control: serverless usage policies (in Preview) attach cost-center tags to all serverless usage, and the system tables system.billing.usage and system.billing.list_prices show consumption and list prices per SKU. According to the release notes, a prebuilt usage dashboard has been generally available since March 2026. For Power BI, connect Desktop or the service to the SQL warehouse through the Databricks connector.
How you know it worked: A Power BI report reads from the SQL warehouse, and its consumption appears in system.billing.usage with the right cost-center tag.
Most common cause of failure: Cost control is added after the first invoice surprises someone. The billing tables are not readable for everyone automatically: a person who is both metastore admin and account admin has to grant access.
Step 10: Hand results back to SAP as a data product
What you do: Each workspace has a preconfigured OpenSharing recipient called sap-business-data-cloud. Create a share (Catalog Explorer, SQL or CLI), add the data and share it. For the result to be discoverable in BDC, the documentation says you must describe it in CSN and ORD using the SAP Business Data Cloud SDK.
How a custom data product is structured on the SAP side, and which decisions you need to make first, is covered in the guide How to Build SAP Data Products. There the sharing protocol is still called Delta Sharing; the SAP Databricks documentation now uses the name OpenSharing throughout.
How you know it worked: The data product can be found in the BDC catalog and used by other BDC applications.
Most common cause of failure: The share exists, but the semantic description is missing. The result is then technically shared but cannot be found in BDC.
Order: Steps 1 to 3 are strictly sequential. Step 2 is the point of no return. Steps 4 to 6 can run in parallel. Step 7 requires steps 3 and 6, step 10 requires step 7.
Getting full value out of it
Efficiency in SAP Databricks is decided in three places: where business logic lives, how reporting queries the data, and whether cost can be attributed.
Business logic in the platform, not in the report. The Power BI guidance in the SAP Databricks documentation is clear: push transformations “left”, meaning core logic as SQL views in Databricks rather than in Power Query and DAX. Use DirectQuery for fact tables and Dual mode for dimension tables, and prefer DirectQuery over Import wherever possible because governance and auditability are preserved.
Define metrics once. General Databricks describes metric views as a shared semantic layer: metrics are defined once and queried across any dimension. The SAP Databricks release notes refer to metric views repeatedly (including parameters in Preview since June 2026), and according to the release notes the Excel add-in in Preview can import from metric views. If you use the same metrics in Power BI, Excel and notebooks, this is the lever against three different revenue figures.
Bring SAP semantics along. SAP table and column names are hard to read; the documentation says so itself. When you access a BDC data product, SAP Databricks automatically takes over table and column descriptions, primary and foreign keys, and the data protection tags. That makes the data usable for analysts, for Genie Code in the editor, and for Genie Agents in natural language, without knowing SAP naming conventions.
Attribute cost before it occurs. One usage policy tag per project or cost center and a regular query on system.billing.usage, and the question “who used this?” is answered in minutes instead of a round of meetings.
Harmonizing several SAP and non-SAP ERP systems: what fits and what does not
The second common question: can SAP Databricks be the harmonization layer across several ERP systems so that shared reporting becomes possible? The answer has two parts.
What fits. The pattern Databricks recommends for this is the medallion architecture: bronze for raw data in its original state, silver for cleansing and validation, gold for business-modeled, aggregated data. The documentation explicitly describes the silver layer as the place for “data cleansing, deduplication, and normalization”, including schema enforcement, type casting and joins. Gold layers may be split by business domain, for example finance, HR and IT. That is exactly the work of a harmonization layer for transactional data: bringing postings, orders and invoices from different systems into one format and building group-wide metrics from them.
Where SAP Databricks sets limits. Three points from the documentation shape this architecture:
- In the SAP edition, non-SAP systems are not connected as source systems; their data arrives through cloud storage, external APIs or OpenSharing. In practice, your other ERP systems have to export their data to a bucket first. That export route sits outside SAP Databricks and has to be operated.
- Foreign keys from SAP data products are only taken over within the same share. Relationships across data product boundaries are yours to model.
- Harmonized results leave SAP Databricks only toward BDC or through queries (SQL warehouse, Power BI, Excel). According to the documentation, an OpenSharing share to a non-SAP destination is not possible.
Where the task becomes a different one. The hardest question in ERP harmonization is rarely the format; it is identity. Is customer 4711 in ERP A the same as customer K-0815 in ERP B? Is the material in the northern plant the same as in the southern one? That is master data management: matching, duplicate resolution and a maintained golden record with owners and an approval process. You can technically deduplicate in a silver table. But deciding which record is authoritative, and maintaining that decision over time, belongs to an MDM discipline, in many organizations on a dedicated platform such as Reltio. The clean division of labor: MDM supplies the mapping table (which local ID belongs to which global object), Databricks applies it in the silver layer and builds the gold layer for reporting on top.
The one-liner for the steering committee: SAP Databricks harmonizes transactional data. It does not decide who a customer is.
Pitfalls
| Symptom | Cause | Prevention |
|---|---|---|
| The wrong colleague holds admin rights over the whole account | The first invited user automatically becomes account admin | Name the first person before provisioning and document it |
| A second region is needed but cannot be created | Accounts support only one region | Agree the region in step 2 with data protection and business units |
| SAP data products can no longer be queried after a network change | IP access list or egress rule breaks the connection to BDC | Read the SAP documentation first, test changes in a test workspace |
| Analysts see personal data they should not see | Read access for all workspace users on SAP shares by default | Narrow rights to groups, ABAC with sap.PersonalData tags |
| Writes to your own bucket fail | External locations must be read-only | Keep results as managed tables or share them to BDC |
| A data product handed back does not show up in BDC | Share without semantic description in CSN/ORD | Build the BDC SDK step into the process |
| Column changes at the data provider are not visible right away | According to the documentation, up to one minute delay for column and share changes | Wait a minute when testing, use “Refresh Table” for metadata |
| The first workspace fills up with test tables | The “default” schema in the workspace catalog is writable for everyone | Own catalogs and schemas per project, production in its own workspace |
A planning note: the SAP edition’s feature lists name scheduled notebooks and scheduled queries. Jobs and Lakeflow pipelines appear only in passing, on pages about networking and cost attribution. If your harmonization is meant to rely on pipelines with dependency management, have their availability in the SAP edition confirmed first.
Checklist
- ☐ BDC subscription in place, BDC admin named
- ☐ First account admin decided
- ☐ Region chosen and approved (cannot be changed)
- ☐ SAP Cloud Identity Services connected, groups synchronized via SCIM
- ☐ Network rules decided and tested against the BDC connection
- ☐ Support personnel access deliberately configured
- ☐ Workspaces separated by environment or team, purpose documented
- ☐ First SAP data products shared, default read rights narrowed
- ☐ ABAC policies based on
sap.PersonalDatatags in place - ☐ External locations for non-SAP data created, read-only
- ☐ Serverless SQL warehouse set up, CAN USE rights granted
- ☐ Usage policies with cost-center tags active, billing tables shared
- ☐ Power BI connected (DirectQuery for facts, Dual for dimensions)
- ☐ Metrics defined as metric views instead of in the report
- ☐ Route back to BDC tested, including CSN/ORD description
- ☐ With several ERP systems: export route to buckets and ownership of master data mapping clarified
Frequently asked questions
Is SAP Databricks a connector between SAP and Databricks? No. SAP data products are shared via OpenSharing and appear as a catalog, according to the documentation without replication. There is no load process for you to operate.
Where does my data live? In SAP-managed storage. The documentation stresses that compute and storage are fully managed and that no additional cloud resources are needed. External buckets are connected read-only.
Can I pass harmonized data to a non-SAP system? Not through an OpenSharing share. Queries via SQL warehouses, Power BI or Excel are possible; a share to destinations outside SAP is not, according to the documentation.
Do I also need an MDM system if I harmonize several ERPs? For transactional data, not necessarily. As soon as customers, suppliers or materials have to be recognized and maintained as the same object across systems, yes. That is a master data decision with its own process, not just a transformation.
Which languages can I use in notebooks? In SAP Databricks, Python and SQL. General Databricks also lists R and Scala.
Can support personnel access my workspace? Only if you allow it, limited to up to 48 hours or permanently. According to the documentation, access is subject to an approval process and recorded in audit logs.
Sources and confidence
All sources retrieved as raw text on 31 October 2026.
- SAP Databricks documentation, What is SAP Databricks? https://docs.databricks.com/sap/en/ (version 29 Oct 2026)
- SAP Databricks admin guide. https://docs.databricks.com/sap/en/admin-guide (version 29 Oct 2026)
- SAP Databricks user guide. https://docs.databricks.com/sap/en/user-guide (version 29 Oct 2026)
- Set up your SAP Databricks account. https://docs.databricks.com/sap/en/provision-account (version 11 Sep 2026)
- SAP Databricks admin best practices. https://docs.databricks.com/sap/en/admin-best-practices (version 29 Oct 2026)
- Share SAP data into SAP Databricks. https://docs.databricks.com/sap/en/share-data (version 15 Oct 2026)
- Publish data from SAP Databricks to SAP BDC. https://docs.databricks.com/sap/en/publish-data-bdc (version 11 Sep 2026)
- Connect to external data sources. https://docs.databricks.com/sap/en/external-data (version 29 Oct 2026)
- Connect to an S3 bucket. https://docs.databricks.com/sap/en/external-locations (version 6 Oct 2026)
- Access data shared with you using OpenSharing. https://docs.databricks.com/sap/en/read-share (version 8 Oct 2026)
- Networking and security. https://docs.databricks.com/sap/en/network-security (version 11 Sep 2026)
- Workspace access for SAP Databricks personnel. https://docs.databricks.com/sap/en/sap/workspace-access (version 11 Sep 2026)
- Data analysis with notebooks. https://docs.databricks.com/sap/en/notebooks (version 15 Oct 2026)
- Business intelligence with Databricks SQL. https://docs.databricks.com/sap/en/sql (version 15 Oct 2026)
- AI and machine learning. https://docs.databricks.com/sap/en/machine-learning (version 6 Oct 2026)
- Database objects in SAP Databricks. https://docs.databricks.com/sap/en/database-objects
- View and query the billing logs. https://docs.databricks.com/sap/en/cost-management (version 11 Sep 2026)
- Attribute usage with serverless usage policies. https://docs.databricks.com/sap/en/admin/usage/budget-policies (version 28 Sep 2026)
- Power BI cheat sheet. https://docs.databricks.com/sap/en/cheat-sheet/power-bi (version 11 Sep 2026)
- SAP Databricks release notes, March and June 2026. https://docs.databricks.com/sap/en/release-notes/2026/march, https://docs.databricks.com/sap/en/release-notes/2026/june
- What is Databricks? https://docs.databricks.com/aws/en/introduction (version 29 Oct 2026)
- What is a data lakehouse? https://docs.databricks.com/aws/en/lakehouse (version 29 Oct 2026)
- What is the medallion lakehouse architecture? https://docs.databricks.com/aws/en/lakehouse/medallion (version 29 Oct 2026)
Not used as evidence: the SAP product page (https://www.sap.com/germany/products/data-cloud/databricks.html, HTTP 403 on retrieval) and the SAP help pages on help.sap.com (content rendered by JavaScript only).
Confidence in the key statements
| Statement | Source | Confidence |
|---|---|---|
| SAP Databricks is a version of Databricks running as an application in BDC | 1 | High |
| Access to BDC data products without replication | 1, 6 | High (vendor statement, not measured) |
| First user becomes account admin, first workspace created automatically | 4 | High |
| Only one region per account | 4, 5 | High |
| All workspace users have read access to SAP shares by default | 5 | High |
| External locations must be read-only | 5, 8, 9 | Medium (contradiction on page 9) |
| No shares to destinations outside SAP | 8, 10 | High |
| Foreign keys only within the same share | 6 | High |
| Silver layer for cleansing, deduplication, normalization | 23 | High |
| Jobs/Lakeflow pipelines available in SAP Databricks | 18, networking pages | Low (only mentioned indirectly) |
Sascha Theismann helps enterprises execute measurable digital transformation – from AI and automation governance to enterprise architecture in the SAP landscape.
