Your SAP data, without losing what it means.
Anyone who has built a warehouse on SAP data knows the real cost. It is not the extraction. It is that a table arrives called KNA1 with eighty columns of three-letter names, and somebody spends six months rebuilding, by hand and from memory, the business meaning SAP already knew. SAP and Databricks have built a connector that does not do that: data products are shared into Unity Catalog with no copy made, and the comments, the keys and the governance tags come with them.
We build and support SAP as well. Our page on SAP Business Data Cloud explains that side of the arrangement — this page is about the Databricks side of the same connection.
- sap_bdcvia OpenSharing
- customerdescribed
- sales_orderkeys intact
- general_ledgertagged: restricted
- materialdescribed
Two arrangements that are easy to confuse.
This confusion costs people real money in procurement conversations, so it is worth being precise before anything else. There are two distinct things, and which one you want changes the commercial discussion entirely.
SAP Databricks
- An SAP-managed version of the Databricks platform.
- Reached from inside SAP Business Data Cloud, as part of it.
- Bought from SAP, governed by SAP’s commercial terms.
- Suits an organisation whose centre of gravity is SAP and who wants one vendor relationship.
Your own Databricks, connected
- Your existing Databricks workspace, with your existing catalogue and commercial terms.
- Connected to SAP Business Data Cloud through the SAP BDC connector over OpenSharing.
- Sharing runs in both directions, with no copy of the data.
- Suits an organisation whose data is not only SAP — which is most of them.
The rest of this page is about arrangement two, because that is the one most of our clients need: SAP is the biggest and most important source, and it is not the only one. If arrangement one is the better fit for you, we will say so — and our SAP Business Data Cloud page covers it from the SAP side.
In both directions, and nothing is copied.
The connector is bidirectional. Which half you use first depends on where your reporting lives today, and most organisations end up using both.
The metadata sync is the part worth getting excited about
When SAP BDC shares are mounted as Unity Catalog catalogues, metadata syncs automatically: table and column comments, primary and foreign keys, and governance tags. That metadata is then usable in Catalog Explorer, in SQL queries, in Genie agents and in governance policies.
Read that list again if you have ever built an SAP warehouse. Keys intact means joins that are correct rather than guessed. Comments mean a Genie space has something to ground an answer in. Governance tags mean a policy like “columns tagged restricted are masked outside Finance” applies to SAP data on arrival, rather than being reconstructed by hand after someone notices.
A four-step handshake between two administrators.
The mechanics are genuinely short. What takes the time is the agreement about what gets shared, which is a governance conversation rather than a technical one — and should be, because a share has no natural end date unless you give it one.
The Databricks administrator generates a connection identifier
and sends it to the SAP BDC administrator. They need a Unity Catalog-enabled workspace with OpenSharing configured, and
CREATE PROVIDERandCREATE RECIPIENTprivileges.The SAP BDC administrator sets up a third-party connection
using that identifier, and returns an invitation link.
The Databricks administrator creates the connection
from the invitation link. The two sides are now joined.
Both sides share and receive
through OpenSharing — SAP shares mounted as catalogues here, Databricks shares granted to SAP BDC recipients there.
Note the shape of that: it needs an administrator on each side, with privileges, at the same time. In practice the scheduling of those two people is the critical path, and it is worth booking before the design work finishes rather than after.
Unity Catalog, enabled
New workspaces have it on by default. Older ones may not, and that is a project of its own.
OpenSharing, configured
Set up in the workspace before the connection can be made.
Two administrators, available
One on each side, with the right privileges, in the same week.
Which data products
Agreed deliberately, not by sharing everything because it is easier.
Who the recipients are
Named, with an owner, and reviewed on a schedule.
What expires, and when
A share without an expiry is a permanent arrangement made by accident.
There is a disclosure clause, and it is specific.
We would be doing you a disservice to leave this out, because it is the kind of sentence that is easy to miss in documentation and expensive to discover later.
What Databricks states
If you use the connector to share SAP BDC data into Databricks, Databricks may disclose usage and operations information to SAP for billing and administrative purposes. That can include data volumes, timing, and your effective Databricks price, identified per workload, not aggregated and not anonymised. Your organisation may be identified.
If your Databricks commercial terms are confidential — and for most organisations that negotiated them properly, they are — then that sentence belongs in your commercial review, not in a footnote. It does not make the connector a bad idea. It makes it a decision that someone in procurement should take knowingly rather than one an engineer takes on a Tuesday.
How the exchange is protected
Data exchanges use mutual TLS and OpenID Connect, with governance and auditing through Unity Catalog.
What stays yours
The grants, the recipients, the retention and the review schedule. The controls that matter most in any cross-company share are the ones you set and then actually revisit.
What the documentation does not cover
The overview page does not list product limitations, pointing instead to separate pages per task. We read those for the specific data products you intend to share rather than assuming parity across all of them.
Nobody has to throw away their extraction pipelines.
Organisations already pulling SAP data out successfully are not disrupted by this, and the connector is an addition rather than an ultimatum. Which raises the better question: is the pipeline you maintain giving you anything the connector does not?
- 1
Map what you extract today
Every job, every table, every consumer. Including the ones nobody has looked at in two years.
- 2
Match it to data products
Which of what you pull is covered by an SAP data product, and which genuinely is not. Be honest about the gaps.
- 3
Run both in parallel
The new path beside the old one, with the numbers reconciled to the penny before anyone switches anything off.
- 4
Retire, one at a time
Consumers moved first, then the job decommissioned. Nothing about this needs to be a big-bang cutover, and it should not be.
For most teams the honest answer at step two is that their pipelines cost a lot of upkeep and lose the semantics on the way through — which is exactly what the connector addresses. But that answer should come from the mapping, not from us.
What you would build on it.
Once SAP data is here with its meaning intact, the rest of the platform becomes considerably more useful.
Genie
The place business users live: governed dashboards, natural-language questions answered from curated data, and the shared metric definitions that keep the answers consistent.
Read it →GovernanceUnity Catalog
Tables, files, models, agents and dashboards in one permission model, with column-level lineage, attribute-based policies and a gateway that governs what AI is allowed to touch.
Read it →Data warehousingLakehouse
SQL analytics on Delta Lake and Apache Iceberg tables in your own cloud storage, with serverless compute, self-tuning layouts and a real-time tier for dashboards and apps.
Read it →Where this leads next.
© 2026 Mawkish Technologies. This guide, its diagrams and illustrations are protected by copyright. You’re welcome to learn from it and to quote it with credit and a link. Reproducing it, by hand or through AI, and publishing it as your own is not allowed. Read our copyright notice
What SAP customers ask us.
What exactly did SAP and Databricks build?
A connector that shares data between SAP Business Data Cloud and Databricks over the open sharing protocol, in both directions, with no copy of the data. SAP BDC shares mount as catalogues in Unity Catalog and are queried from Databricks; Databricks shares can be granted to SAP BDC recipients.
There is also SAP Databricks: an SAP-managed version of the Databricks platform reached from inside SAP Business Data Cloud. They are related but not the same thing, and which one you want changes the commercial conversation.
Does the business meaning survive the trip?
More of it than usual, which is the interesting part. When SAP BDC shares are mounted into Unity Catalog the metadata syncs: table and column comments, primary and foreign keys, and governance tags. That metadata is then usable in Catalog Explorer, in SQL, in Genie agents and in governance policies.
That is the difference between receiving a table called KNA1 and receiving a described customer master with its keys intact. Anyone who has rebuilt SAP semantics by hand in a warehouse knows what that is worth.
Who sets it up, and how long does it take?
It is a four-step handshake between two administrators. The Databricks workspace administrator — who needs CREATE PROVIDER and CREATE RECIPIENT privileges, in a Unity Catalog-enabled workspace with sharing configured — generates a connection identifier and sends it to the SAP BDC administrator, who sets up a third-party connection and returns an invitation link, which the Databricks administrator uses to create the connection. Then both sides share and receive.
The technical steps are short. Agreeing which data products are shared, with whom, and under what retention is the part that takes meetings.
Is anything disclosed to SAP about our Databricks usage?
Yes, and it is worth reading before you sign. Databricks states that if you use the connector to share SAP BDC data into Databricks, it may disclose usage and operations information to SAP for billing and administrative purposes — data volumes, timing, and your effective Databricks price, identified per workload, not aggregated and not anonymised. Your organisation may be identified.
We raise this in the commercial review rather than discovering it in an invoice. If your Databricks pricing is confidential, that sentence matters.
We already extract SAP data into a warehouse. Do we throw that away?
Not necessarily. Existing extraction approaches continue to work, and the connector is an addition rather than an ultimatum. The question is whether a pipeline you maintain is giving you anything the connector does not — and for most teams the honest answer is a lot of upkeep and a loss of semantics.
We would map what you extract today, which of it a data product covers, and retire pipelines one at a time. Nothing about this needs to be a big-bang cutover.
How is it secured?
Exchanges use mutual TLS and OpenID Connect, with governance and auditing through Unity Catalog.
As with any cross-company share, the controls that matter most are the ones you set: which data products, which recipients, which retention, reviewed on a schedule rather than at the moment someone leaves.
We know both sides of this connection.
We build and support SAP, and we build on Databricks. Bring us your SAP landscape and the reporting you cannot get out of it, and we will map which data products cover it, what the connector would carry across, which of your pipelines it retires — and we will flag the disclosure clause before procurement does.
- Your SAP landscape, mapped to data products
- Semantics preserved rather than rebuilt
- Existing extracts retired in sequence
- The disclosure clause raised early
- One team for both sides of the connection
Databricks, Lakehouse, Lakeflow, Lakebase, Unity Catalog, Genie, Agent Bricks, OpenSharing, Delta Sharing and Lakewatch are trademarks of Databricks, Inc. Apache, Apache Spark, Apache Iceberg and Spark are trademarks of the Apache Software Foundation. Delta Lake and MLflow are projects of the Linux Foundation. SAP, SAP Business Data Cloud and SAP Datasphere are trademarks of SAP SE. PostgreSQL is a trademark of the PostgreSQL Community Association. All other names belong to their owners. Mawkish Technologies is not affiliated with, endorsed by or a reseller for Databricks, Inc. Everything described here is taken from material Databricks publishes; product names, availability and prices change, so check the current documentation before you commit to anything. Screens shown are our own illustrations with sample data, not screenshots.
We call our approach to SAP Business Data Cloud and Databricks the Cascroft Gate: advice that stays on your side of the table.