Was ist der Unterschied zwischen SAP Databricks vs Databricks? SAP und Databricks bündeln Ihre Stärken in einem neuen Produkt: SAP Databricks. Wie sich das Produkt vom klassischen Databricks unterscheidet, welche Vorteile sich daraus ergeben und welches Produkt besser zu Ihrem Unternehmen passt, erklären wir Ihnen hier.
SAP Databricks vs. Databricks in 5 Minuten
Unter anderem gehen wir auf die folgenden Punkte ein:
- Welche Zielgruppen von SAP Databricks profitieren
- Die Unterschiede zum nativen Databricks
- Was sind die Voraussetzungen für SAP Databricks
Lesen Sie außerdem:
Lassen Sie uns starten!
Was ist SAP Databricks?
Kurz gesagt: SAP Databricks ist der vereinfachte Zugang zu den SAP-Daten mit den Vorteilen der Databricks Data- und AI-Plattform (Lakehouse Architektur). Also die Schnittstelle zwischen SAP-Daten und AI-Anwendungen, die bisher immer gefehlt hat. Das Produkt gehört zu dem Produktbundle der SAP Business Data Cloud und beinhaltet die Databricks-Kapazitäten:
- Data Science
- ML/AI
- SQL Serverless
Das Produkt ist bereits seit April auf AWS verfügbar, wird dann in GCP öffentlich und schließlich in Q3 2025 in Azure.
„Wer heute schon tief im SAP-Ökosystem steckt und die Cloudstrategie konsequent verfolgt, sollte SAP Databricks definitiv evaluieren.“
– Laurenz Wuttke, CTO Datasolut GmbH
Viele Unternehmen (besonders die mit starkem SAP-Hintergrund) waren bis vor Kurzem nicht in der Lage KI-Anwendungen umzusetzen, da bis dato keine effektive Schnittstelle zwischen SAP-Daten und den KI-Pipelines bestand. Das lag besonders an komplexen ETL-Prozessen und hohen Kosten, die mit der Datenintegration einhergingen.
Durch die Kooperation von SAP mit Databricks bietet der SAP-Kosmos erstmals die Möglichkeit, SAP-Daten einfach über so genannte Datenprodukte für Machine-Learning-Projekte in SAP Databricks zu verwenden.
SAP Databricks in 5 Minuten mit unserem CTO Laurenz.
Der Gedanke hinter der Zusammenarbeit von SAP und Databricks:
Unternehmen sollen ihre SAP-Daten flexibel nutzen können, und zwar ohne komplizierte ETL-Prozesse, Dubletten oder Governance-Risiken.
In der folgenden Grafik sehen Sie den Aufbau der BDC und wie Databricks in diese integriert ist. Wie genau SAP Databricks funktioniert und was dahintersteckt, erklären wir Ihnen im Detail in einem anderen Blogbeitrag: Was ist SAP Databricks?
Für viele Unternehmen mit SAP-Hintergrund ist das ein großer Schritt nach vorne – weil es ihnen endlich erlaubt, SAP-Daten gleichwertig mit anderen Unternehmensdaten zu analysieren, modellieren und visualisieren.
Es erlaubt ihnen, ihre KI/ML Entwicklungen basierend auf ihren eigenen Unternehmensdaten auszubauen, wie:
- Supply-Chain-Optimization
- Financial Forecasting
- Chatbots basierend auf generativer KI
„Ich finde die Zusammenarbeit zwischen SAP und Databricks spannend – wenn es zur Datenstrategie des Unternehmens passt.“
– Vinzent Wuttke, CEO Datasolut GmbH
SAP Databricks bringt eine menge Vorteile mit allerdings speziell für Kunden, die SAP-zentriert arbeiten. Um die Vorteile der Data Products in der BDC besser zu verstehen, lohnt sich ein Blick in die Vergangenheit.
Gängige Integrationsszenarien der SAP Daten in Databricks
SAP-Kunden speichern ihre Daten entweder über Datasphere oder on-premise über das Business Warehouse (BW) (welches offiziell nur noch bis 2030 supportet wird).
Es gibt 3 Möglichkeiten SAP-Daten in Ihr Databricks-Konto zu integrieren:
- Direkt über SAP ERP mit IoT-Daten in Databricks: Eignet sich besonders für ML-Prozesse (z.B. Predictive Maintenance)
- Extraktion direkt aus ERP-Systemen mithilfe von SAP Datasphere
- Über SAP Business Warehouse (BW) in Kombination mit Databricks: Z.B. für den Aufbau eines Data Lakes (Gold/Silber-Schicht)
Herausforderungen der herkömmlichen Integrationsoptionen
Wer SAP-Daten klassisch über ELT-Prozesse in Databricks integrieren möchte, stößt schnell auf technische und organisatorische Hürden:
- Lizenzkosten: Für den Zugriff auf SAP HANA-Daten wird eine Enterprise Edition benötigt – die günstigere Runtime Edition reicht nicht aus.
- Fehlende Timestamps: Viele SAP-Tabellen enthalten keine Zeitstempel, was eine effiziente Change Data Capture (CDC) nahezu unmöglich macht.
- ABAP CDS Views: Diese sind nicht direkt aus der Datenbank lesbar, obwohl sie häufig zentrale Geschäftslogik enthalten.
- Hoher Entwicklungsaufwand: Der gesamte ELT-Prozess muss manuell entwickelt werden – von der Extraktion bis zur Transformation, da SAP keine fertigen Inhalte bereitstellt.
- Abhängigkeit von Partnern: Unternehmen greifen daher oft auf externe ELT-Beschleuniger zurück, z. B. von Tridant oder Cellable, was jedoch zusätzliche Kosten und Abhängigkeiten mit sich bringt.
Das vierte Integrationsszenario: SAP Datenprodukte in der BDC
SAP liefert in der Business Data Cloud kursierte, tortransformierte Datenprodukte (Data Products) mit eigener Business-Logik. Die Produkte sind für typische Geschäftsanwendungen optimiert, zum Beispiel „Customer“, „Cash Flow“, usw. Der Aufwand eigene ETL-Strecken aufzubauen entfällt damit. SAP übernimmt die Datentransformation und -bereitstellung komplett.
Sehen wir uns das im Detail an.
Datenintegration bei SAP Databricks
Die Datenintegration von SAP Daten in Databricks war bisher von aufwändigen ETL-Prozessen geprägt und es gab eine große Herausforderung mit Datenduplikaten, wodurch häufig wichtige Dateninformationen abhanden kamen.
Warum Lakehouses die Daten-Architektur der Zukunft sind
In unserem Whitepaper erfahren Sie:
- Wie sich ein Data Lakehouse von anderen Architekturen unterscheidet.
- Wie Sie durch ein Lakehouse KI-Anwendungen schneller umsetzen.
- Wie Sie ihr internes Team befähigen selbstständig KI Projekte zu implementieren.
Databricks hatte das Problem bereits früh erkannt und als Antwort die Lakehouse-Architektur bereitgestellt. Diese ermöglicht die Integration jeglicher Form von Daten und die Verarbeitung dieser an einem zentralen Ort ohne Datenkopien und mit hohen Sicherheits- und Governance Standards. SAP hat diesen Vorteil von Databricks ebenfalls erkannt:
Durch die Zusammenarbeit mit Databricks mit Hilfe von Delta Sharing (Zero-Copy) und Datenprodukten bietet SAP seinen Kunden nun ein vollständig von SAP gemanagtes Datenökosystem.
Die technische Architektur der BDC sieht dabei wie folgt aus:
- Quellsystem: S/4HANA in SAP RISE Private Cloud (Pflicht für ERP-Datenprodukte).
- Staging: Bronze Layer landet in „HANA Data Lake Files“ (SAP-eigenes Storage).
- Transformation: SAP transformiert zu Silver/Gold intern.
- Bereitstellung: Über Delta Sharing an:
- SAP Databricks (OEM-Version, verkauft durch SAP)
- Native Databricks (direkt vom Kunden lizenziert)
- Konsumption: Visualisierung über SAP Analytics Cloud (SAC), Nutzung in Notebooks, MLflow etc.
Wie das funktioniert, sehen Sie in der folgenden Grafik.
Die SAP Datenquellen S4/HANA auf RISE Private Cloud und SuccessFactors werden in den SAP eigenen Speicher in der BDC geladen. Dieser Speicher ist unabhängig vom Kunden und alle Prozesse innerhalb der BDC werden von SAP gemanagt.
In der BDC transformiert SAP die Daten nach eigener Business-Logik und Semantik und erzeugt so Silber- und Gold-Schichten nach Lakehouse Prinzip. Das Ergebnis sind SAP BDC Datenprodukte mit beispielsweise Informationen zu Kunden oder Cashflow.
Diese Produkte sind
- kuratiert,
- standardisiert
- und können deswegen direkt für Analysen verwendet werden.
Die Bereitstellung der Daten erfolgt über Zero-Copy Delta Sharing entweder an die Databricks OEM-Version innerhalb der SAP BDC oder an das native Databricks (hierfür ist jedoch eine manuelle Annahme erforderlich).
In SAP Databricks können die Produkte direkt für
- AI/ML-Workloads
- oder für SQL-Analysen,
- Notebooks
- und Dashboards verwendet werden.
Vorteile und Herausforderungen der Datenprodukte
Die Vorteile die sich daraus für SAP-Kunden ergeben:
- Nahtlose Integration ohne Datenkopien
- Semantik bleibt erhalten
- AI-Readiness auf Knopfdruck
Jedoch ist das Produkt nicht als Allheilmittel anzusehen, sondern bringt Herausforderungen mit sich:
- Starke Abhängigkeit von SAP
- Eingeschränkte Nutzung von Databricks Funktionen
- Nutzung beschränkt sich auf SAP-Daten (kein CRM, Salesforce,…)
Daher sollten Sie genau abwägen, ob SAP Databricks zu Ihrem Vorhaben passt.
Sie wollen mit SAP Databricks starten? Wir unterstützen Sie!
Von der Entwicklung erster PoCs bis zur Umsetzung konkreter Use Cases. Mit über 10 Jahren Erfahrung in der Entwicklung lösungsorientierter Datenplattformen sind wir der perfekte technische Partner für Ihr Unternehmen.
Kommen wir nun zur zentralen Frage dieses Blogs: Databricks vs. SAP Databricks, was passt besser zu Ihrem Unternehmen?
Native Databricks vs. SAP Databricks – Wann lohnt sich welche Plattform?
Wie Sie sich zwischen Databricks und SAP Databricks entscheiden hängt vor allem mit Ihrer technischen Infrastruktur zusammen. Im Endeffekt ist SAP Databricks eine reduzierte Version von Databricks die von SAP verkauft und gemanagt wird.
- Sind Sie bei SAP stark aufgestellt? Ja.
- Haben Sie ein S/4HANA Konto auf Rise? Ja.
- Dann lohnt sich SAP Databricks.
Liegt Ihr Fokus weniger auf SAP-Daten oder etwa bei 50/50, empfehlen wir Ihnen die Entscheidung abhängig von Ihren zukünftigen Anwendungsfällen zu treffen.
SAP Databricks kann ein sinnvoller Baustein sein, um ML-Workloads effizient auf SAP-Daten umzusetzen, besonders wenn kein Hausinternes Engineering Team vorhanden ist. Jedoch sind Sie dabei stark von SAP abhängig, denn alle Prozesse innerhalb der SAP BDC sind von SAP gemanagt.
Die native Nutzung von Databricks bietet dagegen deutlich mehr Flexibilität – insbesondere für Unternehmen
- mit heterogenen Datenlandschaften
- oder noch laufender SAP-Migration
- oder on-premise SAP Strategie.
Starten Sie jetzt Ihre Databricks Beratung mit Datasolut!
Der Zugang zu SAP-Daten lässt sich auch hier zuverlässig realisieren, etwa durch ETL-Prozesse oder Connectoren (wie Theobald, Azure Data Factory oder FiveTran).
„Viele Kunden integrieren heute schon SAP-Daten in Databricks – das ist erprobt, funktioniert zuverlässig und ist keine Raketenwissenschaft.“
– Vinzent Wuttke, CEO Datasolut GmbH
Sehen wir uns die Unterschiede der einzelnen Merkmale in folgender Tabelle an. Im Anschluss gehen wir ins Detail.
Die Unterschiede pro Merkmal im Detail
Classic/Serverless:
Beim nativen Databricks haben wir die Möglichkeit, unsere Daten flexibel zu speichern. SAP-Seitig sind wir an das HANA-File-System gebunden. Im Punkt Compute haben wir bei SAP Databricks nicht mehr die Möglichkeit individuelle VMs hochzufahren, sondern auf serverless Daten zugreifen kann. Auf dem nativen Databricks können wir unser Compute so gestalten wie wir es möchten:
- Serverless
- Als Classic Compute mit VM auf dem Hyperscaler
- Isoliert
Data Science:
SAP Databricks wurde dafür entwickelt, Databricks-Funktionalitäten wie
- Machine Learning,
- Data Science
- und GenAI in die SAP-Welt zu integrieren.
Jedoch fehlen einige Funktionalitäten, die im nativen Databricks vorhanden sind, wie
- AI/BI-Dashboards
- Lakehouse Federation (für die Anbindung externer Datenquellen)
Databricks bietet den vollen Umfang aller Funktionen, inklusive der Integration externer Datenbanken wie MS SQL, Snowflake oder S3.
DBSQL:
Ein gravierender Unterschied lässt sich im Data Warehouse Bereich, dem DBSQL ausmachen. Im nativen Databricks können wir auf serverless Data Warehouses zurückgreifen oder eine eigene VM zu starten und zu hosten.
Bei SAP hingegen stehen uns nur die Serverfunktionalitäten zur Verfügung. Daneben gibt es weitere Einschränkungen: Wir haben keine Möglichkeit AI/BI zu nutzen und es fehlen Dashboards, die wir auf Databricks produzieren können. Dashboards und Reportings werden in SAP Produkten gemacht.
Connectoren/Kosten:
Das Problem des Datenexports von SAP-Daten wird durch die BDC gelöst, indem dieser über standardisierte Datenprodukte über HANA läuft. Der Zugriff auf den Delta-Sharing-Connector erfolgt durch das BDC-Abo. Das erlaubt non-SAP-Nutzer (Native Databricks User) Zugriff auf alle Daten in BDC zu erhalten.
Für diesen Zugang fallen keine Gebühren für die gemeinsame Nutzung/Extraktion von SAP an. SAP verzichtet auf Gebühren für den SAP-Connector, unabhängig davon, ob der Kunde SAP Databricks verwendet oder nicht. Die Lösung ist für Kunden geeignet die bereits mit Databricks arbeiten und Databricks Daten mit SAP-Daten kombinieren wollen.
Ein entscheidender Vorteil vom nativen Databricks liegt im Lizenzmodell: Während SAP Databricks auf ein Commitment-Modell setzt (fester Kauf von Compute- und Storage-Kontingenten), arbeitet die native Plattform mit dem deutlich flexibleren Pay-as-you-go-Prinzip (Kostenmodell von Databricks). Gerade in frühen Projektphasen ist dies ideal, da die tatsächlichen Bedarfe oft schwer planbar sind.
Data Engineering und Automatisierung:
Bei SAP Databricks werden alle ETL-Prozesse im Hintergrund von SAP übernommen und gemanagt. Über so genannte Datenprodukte stellt SAP in der SAP BDC die Daten in der Silber- oder Goldschicht zur Verfügung. Das erleichtert auf der einen Seite den Datenverarbeitungsprozess für Kunden, die im Data Engineering Sektor eher schwach aufgestellt sind.
Auf der anderen Seite steigert es die Abhängigkeit von SAP und es können keine personalisierten Pipelines gebaut werden. Zudem sind die Datenquellen beschränkt auf SAP-Daten.
Zentrale Features für das Data Engineering die im nativen Databricks vorhanden sind, fehlen hier:
• Workflows
• Autoloader
• Delta Live Table
• Streaming Tables
• Materialized Views
• LakeFlow Connect
Auf native Databricks haben wir die Möglichkeit auch andere Datenquellen außerhalb des SAP-Kosmos zu integrieren und haben verschiedene ETL-Werkzeuge um funktionale und personalisierte Pipelines zu bauen. Wir legen viel Wert auf die einzelnen Engineering-Funktionen von Databricks, zum Beispiel um unseren Kunden Feature Stores aufzubauen oder Pipelines zur Churnprognose zu automatisieren.
Schauen wir uns den Vergleich vom klassischen ETL-Prozess auf Databricks und dem von SAP Databricks im Detail an.
SAP Databricks vs. klassisches ETL auf Databricks
Der große Vorteil mit dem SAP die Business Data Cloud bewirbt sind die so genannte Datenprodukte. Diese machen aufwändige ETL-Prozesse überflüssig und bereiten die Daten so auf, dass sie ohne Semantikverlust für AI/ML-Projekte verwendet werden können.
Konkret bedeutet das:
- Ein schneller Start für Reporting oder KI-Projekte
- Weniger Aufwand aufgrund der vorgefertigten Datenprodukte
- Geringere Kosten dank der Bereitstellung mit Delta Sharing
Jedoch bedeutet es auch:
- Weniger Flexibilität, denn Kunden sind an SAPs Roadmap gebunden
- Weniger Kontrolle bei komplexen ML Use Cases
- Externe Datenquellen die nicht in SAP-Ökosystemen liegen können nur schwer nutzbar gemacht werden
„Ohne Zugriff auf die SAP Data Products, etwa im Silver- oder Gold-Layer, ergibt SAP Databricks keinen Sinn – dafür braucht es zwingend S/4HANA on RISE.“
– Vinzent Wuttke (CEO, Datasolut GmbH)
Die Frage die wir uns stellen sollten: In welchem Fall sind Datenprodukte von Vorteil und wann ist der klassische ETL-Prozess auf Databricks zu empfehlen?
In der Tabelle vergleichen wir die neuen SAP BDC Data Products mit Delta Sharing und die klassische Extraktion mit ETL in Databricks.
| BDC Datenprodukte mit Delta Sharing | ETL in Databricks | |
|---|---|---|
| Engineering-Aufwand | Kein Aufbau eigener DE-Pipelines oder Reverse Engineering nötig – SAP übernimmt dies. | Manuell durch IT-Teams oder Systemintegratoren (DIYs oder Sls) |
| Datenabdeckung | Beschränkt auf die von SAP veröffentlichten Datenprodukte. | Zugriff auf beliebige SAP ERP-Domänen möglich. |
| Unterstützte ERP-Szenarien | Nur S4/HANA auf RISE | Flexibel: ECC, S/4HANA, jedes deployment Model |
| SAP Egress-Gebühr | Keine Egress-Kosten bei Delta Sharing mit Databricks. | Kostenpflichtig über die Datasphere Outbound Integration (POI). |
Wer schnell und ohne tiefgreifendes Engineering starten will, profitiert vom kuratierten Ansatz mit Delta Sharing – nur für RISE-Kunden. Wer maximale Datenqualität und Flexibilität braucht, ist beim klassischen ETL auf Databricks besser aufgestellt.
Unser Fazit
SAP Databricks richtet sich primär an Unternehmen, die ihre Datenstrategie konsequent auf SAP-Technologien wie S/4HANA on RISE ausrichten. Die Plattform ermöglicht Machine Learning und Advanced Analytics direkt auf SAP-Daten – allerdings nur, wenn diese im Rahmen der SAP Data Products (z. B. Gold-/Silver-Datenlayer) verfügbar gemacht werden.
Die Wahl zwischen Databricks und SAP Databricks hängt stark vom Reifegrad der SAP-Cloud-Strategie eines Unternehmens ab. Wer bereits vollständig auf S/4HANA on RISE migriert ist und aktiv SAP Data Products nutzt, kann von SAP Databricks profitieren. Für alle anderen – insbesondere für hybride Datenlandschaften oder Unternehmen mit agiler Datenstrategie – bleibt die native Databricks-Plattform derzeit die bessere Wahl.
Jetzt mit Datasolut den Weg hin zur Data-Driven-Company starten!
Entscheidungshilfe: Databricks oder SAP Databricks
Die Wahl zwischen dem nativen Databricks und SAP Databricks wollen wir Ihnen mit der folgenden Grafik vereinfachen. Besonders die ersten zwei Felder sind entscheidend, nämlich, ob Sie die technischen Voraussetzungen erfüllen. Sind Sie bereits SAP-Kunde und nutzen Sie S/4HANA auf RISE?
Dann steht Ihnen das ganze Potenzial von SAP Databricks zur Verfügung. Denn S/4HANA auf RISE ist die Grundlage für die BDC Data Products.
SAP Databricks vs. Databricks Entscheidungshilfe
SAP Databricks, wenn…
- …Sie SAP als zentrales System nutzen und alle Daten in SAP-Systemen liegen
- … Sie alle Voraussetzungen für die BDC Data Products erfüllen (S/4HANA on Rise)
- …Ihr Use Case eher analytisch als engineering-lastig ist
- …Sie Governance und Sicherheit integriert in SAP nutzen möchten (z.B. den Unity Catalog)
Klassisches Databricks, wenn…
- …Sie komplexe Data Engineering Prozesse haben
- …Sie außerhalb des SAP-Universums arbeiten
- …Sie ein Expertenteam im Bereich Data Engineering und Machine Learning haben
Unsere Empfehlung: Wir analysieren Ihre Datenarchitektur, SAP-Landschaft und Business-Ziele und sagen Ihnen klar, ob SAP Databricks zu ihren Anforderungen passt.
Fazit: SAP Databricks ist kein Tool – sondern eine strategische Entscheidung
Für viele Unternehmen ist SAP Databricks die Chance, Analytics, Reporting und Machine Learning endlich auch auf SAP-Daten produktiv umzusetzen – ohne dabei Abstriche bei Sicherheit oder Datenqualität zu machen.
Die Wahl zwischen Databricks und SAP Databricks hängt jedoch stark vom Reifegrad der SAP-Cloud-Strategie Ihres Unternehmens ab. Wer bereits vollständig auf S/4HANA on RISE migriert ist und aktiv SAP Data Products nutzt, kann von SAP Databricks profitieren. Für alle anderen – insbesondere für hybride Datenlandschaften oder Unternehmen mit agiler Datenstrategie – bleibt die native Databricks-Plattform derzeit die bessere Wahl.
Als offizieller Databricks Partner mit tiefem SAP-Verständnis sind wir von Datasolut Ihr idealer Ansprechpartner. Wir beraten Sie unabhängig, hands-on und mit dem Ziel, aus Ihren Daten echte Wettbewerbsvorteile zu machen.
Lassen Sie uns sprechen und Ihr Potenzial entdecken.
Ob und wie künstliche Intelligenz Ihnen weiterhelfen kann, können Sie in einem ersten, unverbindlichen Gespräch mit uns herausfinden.
In diesem Gespräch erfahren Sie:
- Wie Ihr Use-Case technisch am besten umgesetzt werden kann
- Wie wir maximal sicher mit Ihren Kundendaten umgehen
- Wie lange wir für die Umsetzung benötigen und wie ein konkreter Projektplan aussehen könnte
FAQ – Die wichtigsten Fragen schnell beantwortet
Für die standard ERP Datenprodukte von SAP benötigen Sie S/4HANA auf RISE. Dabei handelt es sich um ein lizensiertes Abo-Modell in welchem das Management der SAP Apps wie ERP oder BW auf Hyperscalers enthalten ist. Außerdem managed die Cloud Admin Funktionen wie Software Updates.
Databricks ist eine offene Datenplattform für Big Data, ML und AI auf Basis von Apache Spark. SAP Databricks ist eine angepasste Version davon, die von SAP als Teil der Business Data Cloud bereitgestellt wird – jedoch nur für Kunden mit SAP S/4HANA on RISE und Zugriff auf die SAP Data Products.
SAP Databricks richtet sich an Unternehmen, die bereits tief im SAP-Ökosystem verankert sind, insbesondere solche mit aktiver Nutzung von S/4HANA on RISE. Nur dann lassen sich die Vorteile der engen Integration wirklich nutzen.
Wenn ein Unternehmen heterogene Datenquellen hat, noch nicht vollständig auf S/4HANA migriert ist oder maximale Flexibilität bei Kosten und Technologie wünscht, ist die native Databricks-Plattform die bessere Wahl.
Ja, in der Regel. Da SAP, Databricks und der jeweilige Hyperscaler (AWS, Azure, GCP) alle mitverdienen, ist SAP Databricks teurer als eine native Databricks-Nutzung.
Ja. Die Integration von SAP-Daten in Databricks ist etabliert und funktioniert zuverlässig – etwa über ETL-Prozesse oder spezialisierte Konnektoren. Dies ist ein häufig gewählter Weg bei hybriden Architekturen. Ein neuer Weg über SAP BDC Data Products ist jetzt neu hinzugekommen.
