SAP Databricks vs. Enterprise Databricks: Kosten, Features, Governance

SAP Databricks ist die in SAP Business Data Cloud eingebettete Databricks-Umgebung. Sie ist darauf ausgelegt, Datenprodukte aus der BDC direkt in Databricks zu analysieren, anzureichern und weiterzuverarbeiten.

Der größte Vorteil liegt im Zugang zu kuratierten SAP-Datenprodukten. Diese können per Zero Copy in Databricks bereitgestellt und dort mit Unity Catalog, Notebooks, SQL sowie AI- und ML-Funktionen genutzt werden. Metadaten aus dem SAP-Kontext, zum Beispiel Beschreibungen, Schlüsselbeziehungen oder Governance-Tags, werden dabei mitgeführt und erleichtern die fachliche Einordnung der Daten.

SAP Databricks passt vor allem zu Unternehmen, die SAP Business Data Cloud als zentralen Bestandteil ihrer Datenstrategie gesetzt haben. Fachbereiche und Datenteams können bereitgestellte SAP-Datenprodukte auswerten, mit weiteren Daten anreichern und daraus neue Datenprodukte für den SAP-Kontext entwickeln.

Der Schwerpunkt liegt klar auf der Arbeit mit SAP-Daten innerhalb der BDC. Für eine unternehmensweite Datenplattform mit vielen Non-SAP-Quellen, eigenen Betriebsstandards und breiteren Engineering- oder AI-Anforderungen ist der Funktionsumfang stärker begrenzt.

Die frühe Kurzfassung „SAP Databricks ist Databricks ohne Auto Loader, Pipelines und AI-Funktionen" stimmt nicht mehr. SAP Databricks unterstützt inzwischen Auto Loader, Lakeflow Spark Declarative Pipelines, Model Serving, Vector Search, AI Gateway, Custom Agents, Agent Evaluation und weitere Teile des Databricks-Stacks.

Vollständige Funktionsgleichheit besteht trotzdem nicht. SAP Databricks bleibt eine eigene, auf SAP Business Data Cloud zugeschnittene Edition. Die Unterschiede zeigen sich heute vor allem beim Betriebsmodell, beim Zugriff auf Storage, bei der Verteilung von Datenprodukten und bei Plattformdiensten, die über Analytics und AI hinausgehen.

Stand der Gegenüberstellung: 12. Juli 2026. Einzelne Funktionen werden gestaffelt nach Cloud und Region ausgerollt.

Die Tabelle zeigt auch, warum eine reine Liste fehlender Data-Engineering- oder AI-Funktionen inzwischen am Thema vorbeigeht. SAP Databricks deckt die meisten typischen Analyse-, Engineering-, ML- und GenAI-Aufgaben ab. Für Teams, die BDC-Datenprodukte verarbeiten, mit externen Read-only-Daten verbinden und anschließend wieder nach BDC veröffentlichen, ist der Funktionsumfang erheblich breiter als zum Marktstart.

Die Grenzen werden sichtbar, wenn Databricks die zentrale Unternehmensplattform werden soll. Dann geht es um beschreibbaren eigenen Storage, frei konfigurierbares Compute, offene Bereitstellung von Datenprodukten, ein vollständiges API- und IaC-Modell sowie Dienste wie Databricks Apps, Marketplace oder Lakebase.

SAP Databricks kann Daten aus S3, Azure Data Lake Storage und Google Cloud Storage einbinden. Diese Speicherorte können mit Unity Catalog abgesichert und aus Notebooks, SQL, Jobs oder Pipelines gelesen werden. Externe Locations und die zugehörigen Storage Credentials müssen im SAP-Betriebsmodell jedoch als Read-only konfiguriert werden.

Das reicht aus, um externe Daten mit SAP-Datenprodukten zu verknüpfen. Es reicht nicht für eine Architektur, in der der kundeneigene Cloud-Storage das beschreibbare Fundament des Lakehouse bildet. Eigene Silver- und Gold-Datenprodukte lassen sich dort nicht frei als externe Tabellen ablegen und anschließend von weiteren Plattformen nutzen.

Enterprise Databricks lässt diesen Spielraum offen. Das Datenteam kann festlegen, welche Daten als Managed Tables in Databricks liegen, welche Tabellen in eigenen External Locations geschrieben werden und welcher Storage langfristig das System of Record bleibt.

SAP Databricks kann Shares von anderen Databricks-Accounts und von offenen Sharing-Providern empfangen. Ausgehend gilt eine klare Grenze: Der Workspace kann Datenprodukte über die vorkonfigurierte OpenSharing-Verbindung an den eigenen SAP-BDC-Account veröffentlichen, aber nicht als allgemeiner Provider für Empfänger außerhalb dieses Accounts auftreten.

Das wird relevant, wenn Datenprodukte direkt an Tochtergesellschaften, Partner, Kunden, andere Databricks-Accounts oder Plattformen wie Snowflake und Microsoft Fabric verteilt werden sollen. In SAP Databricks muss dieser Weg über BDC oder eine zusätzliche Plattformkomponente geführt werden. Enterprise Databricks kann die Shares über Delta Sharing selbst bereitstellen.

Für eine Plattformstrategie ist diese Einschränkung häufig wichtiger als ein fehlendes UI-Feature. Sie bestimmt, ob SAP BDC zwingend als Verteilschicht zwischen Databricks und allen weiteren Konsumenten liegt.

SAP Databricks enthält inzwischen einen breiten AI-Stack. Vector Search, Model Serving, AI Gateway, Custom Agents und Agent Evaluation stehen zur Verfügung. Die Plattform endet jedoch dort, wo aus Daten und Modellen eigenständige Anwendungen oder neue Plattformdienste werden sollen.

Databricks Apps, Databricks Marketplace und Lakebase werden in der aktuellen SAP-Dokumentation ausdrücklich als nicht unterstützt genannt. Auch Genie Agents gehören derzeit nicht zum SAP-Umfang, obwohl Genie Code und Custom Agents verfügbar sind.

Das betrifft beispielsweise interne RAG-Anwendungen, operative Eingabemasken, Data Apps, kundenspezifische Self-Service-Portale oder transaktionale Anwendungen mit Lakebase. Solche Anwendungen benötigen außerhalb von SAP Databricks eine zusätzliche Laufzeit und ein eigenes Deployment-Modell.

Unterstützt sind Git Folders, Asset Bundles (DABS), Lakeflow Jobs und Lakeflow Pipelines. Daraus sollte jedoch keine vollständige API-Parität mit Enterprise Databricks abgeleitet werden.

Databricks führt für die SAP-Edition eine eigene Liste zulässiger APIs. Die aktuelle Referenz enthält unter anderem APIs für Workspace-Dateien, MLflow, Model Serving, Vector Search, SQL Warehouses, Unity Catalog und OpenSharing. Jobs-, Pipelines-, Dashboard-, Apps- und Marketplace-APIs sind dort aktuell nicht aufgeführt.

Für kleinere Umgebungen fällt das kaum auf. Bei mehreren Workspaces, automatisierten Deployments und strikten CI/CD-Vorgaben kann es zum Beschaffungskriterium werden. Vor der Entscheidung sollte deshalb geprüft werden, welche Ressourcen über UI, DABS, CLI, REST API oder Terraform wirklich erstellt und verwaltet werden können.

SAP Databricks nimmt dem Datenteam viel Plattformbetrieb ab. Compute und Storage sind verwaltet, die BDC-Verbindung ist vorkonfiguriert und SAP-Datenprodukte landen mit ihren semantischen Metadaten direkt in Unity Catalog. Für eine SAP-zentrierte Analytics- und AI-Umgebung ist das ein konkreter Vorteil.

Mit dem verwalteten Modell gibt das Unternehmen jedoch einen Teil der Architekturentscheidungen ab. Das Team kann keine klassischen Cluster einsetzen, keinen eigenen Storage als frei beschreibbares Lakehouse-Fundament verwenden, keine externen Sharing-Empfänger anlegen und bestimmte Plattformdienste nicht nutzen. Auch Metastore-, Netzwerk- und API-Konfiguration bleiben enger vorgegeben.

Enterprise Databricks verlangt mehr Plattformverantwortung. Dafür kann das Datenteam selbst festlegen, wie Compute, Storage, Netzwerk, CI/CD, Data Sharing und operative Anwendungen aufgebaut sind.

Die Beschaffungsfrage lautet daher nicht, ob SAP Databricks inzwischen „genug Features" hat. Zu klären ist, ob die vorgesehenen Workloads innerhalb des SAP-Betriebsmodells bleiben können oder ob Databricks als eigenständige Plattform über den BDC-Kontext hinaus funktionieren muss.

Beim Preisvergleich reicht es nicht, Capacity Units und DBUs gegenüberzustellen. Am Ende zählen Vertragsmodell, Workload-Mix, Infrastrukturkosten und ausgehandelte Rabatte.

SAP Databricks wird über den BDC-Core-Vertrag in Capacity Units (CUs) abgerechnet. CUs können für verschiedene BDC-Dienste eingesetzt werden. Innerhalb dieser CUs gibt es eigene Verbrauchspositionen für Compute, SQL, Model Serving, Training, Storage und Netzwerk. Über system.billing.usage, Tags und Serverless Usage Policies lässt sich der Verbrauch nach Job, Nutzer oder Projekt auswerten.

Enterprise Databricks wird direkt über Databricks oder den Cloud-Anbieter bezogen. Die Plattformkosten richten sich nach DBU-Verbrauch und Produkttyp. Bei Classic Compute kommen die Infrastrukturkosten des Hyperscalers hinzu, bei Serverless sind sie bereits eingerechnet. Volumen und Commitments werden direkt mit Databricks beziehungsweise dem Cloud-Anbieter verhandelt.

Für die Beschaffung zählt deshalb der effektive Preis des geplanten Workload-Mixes: Wie viel entfällt auf Jobs, SQL, interaktive Entwicklung, ML, Storage und Netzwerk? Welche Rabatte gelten? Und wie flexibel lässt sich das zugesagte Volumen nutzen?

Auch SAP Databricks verursacht Kosten für Storage, Netzwerkzugriffe und Egress. Im Hybrid-Modell können zusätzlich verbrauchsabhängige Kosten für BDC Connect und den Datentransfer zwischen SAP BDC und Enterprise Databricks entstehen. Beide Plattformen sollten deshalb möglichst in derselben Cloud und Region liegen.

SAP Databricks kann sich rechnen, wenn bereits ein größeres BDC-Commitment besteht und die gebuchte Kapazität auch für andere SAP-Dienste genutzt wird.

Enterprise Databricks kann günstiger sein, wenn viele Workloads außerhalb der SAP-Landschaft laufen und das Databricks-Volumen direkt verhandelt wird. Ein direkter Vertrag schafft außerdem mehr Spielraum bei Compute, Storage und Netzwerk.

Für einen sauberen Vergleich sollten vier Kostenblöcke getrennt betrachtet werden:

• Compute je Workload
• Storage und Storage Requests
• Netzwerk, Egress und BDC Connect
• Commitments, Rabatte und ungenutzte Kapazitäten

Wie die DBU-Abrechnung funktioniert und an welchen Stellen sich Kosten steuern lassen, zeigen wir im Databricks Pricing Guide.

Enterprise Databricks passt, wenn Databricks als zentrale Daten- und KI-Plattform über die SAP Business Data Cloud hinaus eingesetzt werden soll. Unternehmen können Compute, Storage, Netzwerk, Automatisierung und Data Sharing dabei weitgehend selbst gestalten.

Der Enterprise-Pfad bietet sich vor allem in diesen Fällen an:

Enterprise Databricks eignet sich damit vor allem für Plattformen mit vielen Datenquellen, offenen Datenprodukt-Architekturen und einer Analytics- oder KI-Roadmap, die über die BDC hinausgeht.

SAP bleibt Teil dieser Architektur. BDC-Datenprodukte lassen sich ohne zusätzliche Kopie einbinden und gemeinsam mit ihren fachlichen Metadaten in Unity Catalog übernehmen.

Einen Überblick über das Databricks-Portfolio außerhalb der SAP-Welt geben wir unter Databricks bei ruhrdot. Den Vergleich mit einem stärker auf Data Warehousing ausgerichteten Ansatz zeigen wir unter Databricks vs. Snowflake.

Der Wechsel ist möglich, geht aber über einen einfachen Workspace-Umzug hinaus. Notebooks und Quellcode lassen sich meist schnell übertragen. Datenstrukturen, Berechtigungen, Workflows und Betriebsprozesse müssen im Enterprise-Workspace neu eingerichtet werden.

In den meisten Fällen empfiehlt sich deshalb ein schrittweiser Übergang mit beiden Plattformen.

1. 01

   SAP-Datenprodukte neu anbinden

   Freigegebene BDC-Datenprodukte müssen nicht aus SAP Databricks kopiert werden. Der Enterprise-Workspace kann über BDC Connect direkt mit derselben SAP Business Data Cloud verbunden werden. Die Datenprodukte werden dort erneut in Unity Catalog eingebunden. Beschreibungen, Schlüsselbeziehungen und Governance-Tags werden dabei ebenfalls aus der BDC übernommen.

2. 02

   Code, Workflows und eigene Datenprodukte übertragen

   Notebooks lassen sich exportieren und Git-Repositories im neuen Workspace erneut verbinden. Jobs, Pipelines, Secrets, Service Principals und Berechtigungen müssen neu angelegt und getestet werden. Bei eigenen Tabellen hängt der Aufwand davon ab, wo die Daten liegen: Managed Tables befinden sich im SAP-verwalteten Storage, externe Speicherorte lassen sich in SAP Databricks nur lesen. Für eigene Datenprodukte gibt es daher zwei typische Wege: im Enterprise-Workspace aus den ursprünglichen Quellen neu aufbauen, oder erst in die BDC veröffentlichen und anschließend über BDC Connect einbinden.

3. 03

   Governance und Betrieb neu einrichten

   Catalogs, Schemas, Ownership, Grants, Row Filters, Column Masks und eigene Tags werden nicht automatisch in den neuen Account übertragen. Auch Identity Management, Netzwerk, Monitoring und Kostensteuerung müssen im Enterprise-Workspace neu aufgesetzt werden. Die von SAP verwalteten Metadaten werden wieder synchronisiert, sobald die BDC-Datenprodukte dort eingebunden sind.

• Die Anforderungen bleiben nah an SAP: SAP Databricks weiter nutzen.
• Die Plattform wächst schrittweise über SAP hinaus: Enterprise Databricks parallel aufbauen und neue Multi-Source-Workloads dort entwickeln.
• Eigener Storage, offene Sharing-Ziele oder frei konfigurierbares Compute werden benötigt: Die betroffenen Workloads vollständig verlagern.
• Eigene Daten- und KI-Anwendungen sind geplant: Den benötigten Funktionsumfang prüfen. Databricks Apps und weitere operative Dienste sprechen für Enterprise Databricks.

Der Parallelbetrieb sollte eine Übergangsphase bleiben. Zwei dauerhaft getrennte Plattformen erhöhen den Aufwand für Governance, CI/CD, Support und FinOps.

SAP Note 3255746 betrifft Drittanbieter-Tools, die SAP-Daten über ODP-RFC extrahieren. Seit Juni 2026 schränkt SAP nicht autorisierte Zugriffe technisch stärker ein.

BDC Connect ist dafür kein allgemeiner Ersatz. Der Connector stellt freigegebene Datenprodukte aus der SAP Business Data Cloud bereit, ersetzt aber keine direkte Extraktion aus jedem ECC-, S/4HANA- oder BW-System.