SAP BW ablösen mit Databricks: Der komplette Migrationsleitfaden 2026

SAP BW 7.5 verliert im Dezember 2027 die Mainstream-Maintenance. Ohne Migrationsstrategie finanziert ihr Dual-System-Betrieb: HANA-Lizenzkosten für ein System ohne Weiterentwicklung und parallel den Aufbau der Cloud-Plattform.

Vier Migrationspfade stehen zur Wahl: Brownfield (Evolution), Greenfield (Clean Slate), Hybrid (Koexistenz) und Direkt ohne BDC, jeder mit klaren Trade-offs.

SAP Databricks (OEM) reduziert operative Komplexität, aber Native Databricks liefert das volle Feature-Set für heterogene Landschaften und AI.

Governance mit Unity Catalog, Delta Sharing und DSGVO-konformer Compliance gehört von Tag eins in die Architektur, nicht als Nachgedanke.

Dezember 2027. Dann endet die Mainstream-Wartung für SAP BW 7.5, und damit die Komfortzone für tausende Unternehmen, die ihr Reporting seit Jahrzehnten auf dem SAP Business Warehouse aufgebaut haben. Wer bis dahin keinen Migrationsplan hat, zahlt doppelt: für ein Legacy-System ohne Weiterentwicklung und für die Cloud-Plattform, die es eigentlich ablösen soll. Das ist kein technisches Risiko. Das ist ein strategisches.

Die Migration von SAP BW zu Databricks ist dabei keine reine Infrastruktur-Übung. Sie ist die Chance, eine über Jahre gewachsene Reporting-Landschaft in eine AI-fähige Datenplattform zu überführen, mit offenen Formaten, entkoppeltem Compute und zentraler Governance. Dieser Guide zeigt dir die drei konkreten Migrationspfade, vergleicht die Extraktionsprotokolle im Detail und benennt die Fehler, die wir bei Enterprise-Migrationen am häufigsten sehen.

Die Mainstream-Maintenance für SAP BW 7.5 endet im Dezember 2027. Nach diesem Zeitpunkt liefert SAP keine funktionalen Updates und keine regulären Support-Pakete mehr. Für Unternehmen auf BW 7.x heißt das konkret: jede nicht-migrierte Landschaft wird zum offenen Risiko, regulatorisch, technisch und wirtschaftlich.

Die Deadline bedeutet allerdings kein absolutes Aus. Für Systeme, die in die SAP Business Data Cloud (BDC) migriert werden, garantiert SAP die Mainstream-Maintenance bis 2030 (BW PCE) beziehungsweise bis 2040 (BPC/4HANA). Das verschafft Spielraum, der sinnvoll genutzt werden sollte.

Klassische SAP-BW-Landschaften leiden unter drei Problemen, die sich mit jedem Jahr verschärfen. Compute und Storage sind in HANA gekoppelt, wodurch die Kosten mit dem Datenvolumen exponentiell wachsen, nicht linear. Die Datenlatenz liegt häufig bei Stunden oder Tagen, weil BW-Systeme für Batch-Reporting konzipiert wurden, nicht für Echtzeit-Entscheidungen. Und über Jahrzehnte hat sich technische Schuld angesammelt: undokumentierte ABAP-Logik, inkonsistente Schemas, undurchsichtige Abhängigkeiten zwischen InfoCubes und DataStore Objects.

Diese Schuld besteht oft aus "Tribal Knowledge", das in keiner Dokumentation steht. Wer sie ignoriert, baut die gleichen Probleme in der neuen Plattform nach. Wer sie systematisch adressiert (etwa durch eine automatisierte Unused-Asset-Analyse), kann den Migrationsumfang erfahrungsgemäß um 30–50% reduzieren. Weniger zu migrieren bedeutet nicht nur geringere Projektkosten, sondern auch eine schlankere Zielarchitektur.

SAPs eigene Modernisierungsstrategie (die "Clean Core"-Methodik, die Deloitte und SAP gemeinsam vorantreiben) zielt darauf ab, Legacy-Anpassungen und komplexe ABAP-basierte Logik vom ERP-Kern zu entkoppeln. Das ist die Voraussetzung für Cloud-native Agilität und parallel oft der eigentliche Auslöser für eine BW-Migration: wenn der ERP-Kern auf S/4HANA wechselt, muss auch das Data Warehouse mitziehen. Wer beides parallel betreibt (altes BW und neues S/4HANA) verbrennt das ROI der Transformation in doppelten Lizenz-, Betriebs- und Personalkosten.

Die Partnerschaft zwischen SAP und Databricks mündete Anfang 2025 in der SAP Business Data Cloud (BDC). Forrester beschreibt BDC als "Suite as a Service": SAPs Business-Logik wird mit Databricks Engineering-Power kombiniert. BDC ist kein einzelnes Tool, sondern ein Data Fabric, das SAP Datasphere, SAP Analytics Cloud (SAC) und eine OEM-Version von Databricks (SAP Databricks) auf einer gemeinsamen Architektur vereint.

Die wichtigste architektonische Neuerung in BDC: Analytische Workloads laufen nicht mehr auf teurem HANA-In-Memory-Storage, sondern auf kostengünstigem Cloud Object Storage im offenen Delta-Lake-Format. Das ermöglicht Zero-Copy-Integration über das Delta-Sharing-Protokoll: Databricks greift direkt auf SAP-Daten am Speicherort zu, ohne physische Replikation. Keine Egress-Kosten, keine Datenkonsistenz-Risiken, keine redundanten Kopien.

Beide Schichten speichern Daten als Delta Lake Tables auf SAP HANA Cloud, Data Lake Files (HDLF), dem kostengünstigen Object Store, der auf dem jeweiligen Hyperscaler (S3, ADLS Gen2, GCS) aufsetzt. Die Foundation Services (FOS) sind SAP-verwaltet: sie replizieren, harmonisieren und kuratieren SAP-Datenprodukte in einer Medallion-Architektur, auf die Kunden nur lesend über Delta Sharing zugreifen. Der Datasphere Object Store dagegen ist kundenseitig verwaltet. Hier liegen eigene Tabellen, Erweiterungen und Custom-Datenprodukte. Diese Trennung entkoppelt teuren HANA-In-Memory-Compute von hochvolumigem analytischem Storage auf HDLF, das zentrale Kostenproblem der alten BW-Welt.

Wer im BDC-Kontext mit Databricks arbeitet, steht vor einer grundlegenden Entscheidung: die OEM-Version (SAP Databricks) oder die native Databricks-Version. Die Unterschiede sind nicht kosmetisch. Sie bestimmen, was eure Datenplattform langfristig leisten kann.

Betriebsmodell: SAP Databricks (OEM) bietet Managed SaaS (Serverless, kein DevOps nötig), während Native Databricks als PaaS fungiert und eigene Infrastruktur-Verwaltung erfordert.

Integrationsfokus: SAP Databricks (OEM) ist tief in BDC/Datasphere integriert. Native Databricks ist system-agnostisch und für heterogene Landschaften optimiert.

Tooling: In der OEM-Version stehen Notebooks, SQL und MLflow zur Verfügung. Die native Version bietet zusätzlich DLT (Spark Declarative Pipelines), Auto Loader und den Marketplace.

AI-Fähigkeiten: Während SAP Databricks auf Mosaic AI für SAP-Daten setzt, bietet Native Databricks das volle Spektrum: Agentic AI, AI/BI Genie und RAG.

Data Sharing: SAP Databricks (OEM) erlaubt Sharing nur innerhalb des BDC-Ökosystems. Native Databricks ermöglicht offenes Sharing mit jedem OIDC-kompatiblen Empfänger.

SAP Databricks reduziert die operative Komplexität erheblich: Compute und Storage-Verbindungen verwaltet SAP BDC, CI/CD-Pipelines entfallen weitgehend. Der Trade-off ist real: zentrale Features wie Databricks Auto Loader für Real-Time-File-Streams und Delta Live Tables für automatisierte Orchestrierung fehlen in der OEM-Variante.

SAP Databricks passt, wenn eure Datenwelt überwiegend SAP ist, euer Team keine DevOps-Kapazität mitbringt und ihr primär BI- und Data-Science-Workloads innerhalb des SAP-Ökosystems fahrt. Native Databricks lohnt sich, sobald ihr heterogene Datenquellen (SAP + non-SAP) vereinen wollt, fortgeschrittene Data-Engineering-Features braucht oder Daten mit externen Partnern über offene Protokolle teilen müsst.

Es gibt keinen One-Size-Fits-All-Ansatz für die Migration von SAP BW zu Databricks. Consultancies wie LTIMindtree und Eviden haben drei standardisierte Pfade etabliert, die sich an Investitionsumfang, Legacy-Tiefe und Zeithorizont orientieren.

Der Brownfield-Ansatz eignet sich für Organisationen mit massiven Investitionen in BW 7.x oder BW/4HANA, die ihre bestehende Logik weder wegwerfen können noch wollen. Das BW-System wird in die Private Cloud Edition (PCE) der Business Data Cloud migriert, und der "Data Product Generator" konvertiert bestehende BW-Objekte in moderne Datenprodukte. BI-Workloads bleiben in Datasphere, AI/ML-Workloads wandern auf Databricks.

Vorteil: Geringes Risiko, schrittweise Transition, Business-Logik bleibt erhalten. Nachteil: Längerer Migrationszeitraum, keine sofortige Entkopplung von HANA-Kosten.

Das Greenfield ist eine "Clean Slate"-Strategie, die häufig parallel zu einer S/4HANA-Migration läuft. Die Legacy-BW-Logik wird komplett umgangen. Stattdessen nutzt ihr die nativen BDC Foundation Services, um kuratierte S/4HANA-Datenprodukte direkt zugänglich zu machen.

Vorteil: Maximale Modernisierung, kein Legacy-Ballast, AI-ready von Tag eins. Nachteil: Hoher Initialaufwand, ABAP-Logik muss vollständig neu implementiert werden.

Der Hybrid-Ansatz ist typisch für Unternehmen, die Databricks bereits für non-SAP-Daten nutzen. Der BDC-Databricks Connect Service vereint SAP- und non-SAP-Daten über Delta Sharing. SAP Datasphere bleibt für governed BI zuständig, während Databricks die Advanced Data Science und das schwere Data Engineering übernimmt.

Vorteil: Schnelle Integration bestehender Databricks-Investitionen, flexible Architektur. Nachteil: Höhere Komplexität in Governance und Datenlineage.

Nicht jede Organisation will oder kann den BDC-Weg gehen. Eine direkte Migration von SAP BW beziehungsweise S/4HANA nach Databricks ist ebenfalls möglich, ohne Datasphere als Zwischenschicht. Der entscheidende Trade-off: SAP-Semantiken wie Hierarchien, Währungsumrechnungen, Fiskaljahreskalender und Business-Logik aus BW-Extraktoren gehen dabei verloren. Diese müssen im Lakehouse eigenständig nachgebaut werden, in dbt, Spark oder SQL. Das ist machbar, erhöht aber den initialen Engineering-Aufwand und erfordert tiefes Verständnis der SAP-Geschäftslogik im Data-Engineering-Team.

Wichtig dabei: Direkter Datenbankzugriff via JDBC auf HANA ist lizenzrechtlich kritisch. SAP kann für sogenannten "Indirect Digital Access" Nachlizenzierungen fordern. Data Movement Platforms wie Fivetran umgehen dieses Problem, indem sie über SAP-zertifizierte Schnittstellen (RFC, ODP) extrahieren, lizenzkonform, mit integriertem CDC und ohne eigene Middleware.

Vorteil: Keine SAP-BDC-Lizenz nötig, volle Kontrolle, kein Vendor Lock-in auf SAP-Seite. Nachteil: SAP-Semantiken müssen manuell im Lakehouse nachgebaut werden. Direkter DB-Zugriff birgt Lizenzrisiken.

Die technische Basis jeder SAP-BW-Migration sind die Extraktionsmechanismen, mit denen SAP-Daten in Databricks gelangen. Je nach Use Case (Echtzeit-Replikation, Business-Logik-Erhalt oder Compliance-Anforderungen) eignen sich unterschiedliche Protokolle.

SLT: Arbeitet auf der logischen Schicht der HANA DB (Trigger-basiert) mit einer Latenz von < 5s. Die primäre Stärke ist die Real-Time-Replikation von Rohtabellen.

ODP/ODQ: Arbeitet auf der Applikationsebene (Delta Tokens) mit einer Latenz von < 5s. Die Stärke liegt im Erhalt von Business-Logik und Extraktoren.

OData: Nutzt die API-Ebene (Services) mit einer Latenz im Sub-Minute-Bereich. Ideal für Compliance und eine lückenlose Audit-Übersicht.

JDBC: Ermöglicht direkten DB-Zugriff mit variabler Latenz. Besonders stark bei schnellen Full Loads für On-Premise HANA-Systeme.

Fivetran: Fungiert als Data Movement Platform (RFC) mit einer Latenz im Minutenbereich. Die Stärke ist Managed CDC ohne eigene Middleware.

Der SAP Landscape Transformation Replication Server (SLT) liefert trigger-basiertes Change Data Capture auf HANA-DB-Ebene. SLT erfasst Änderungen trigger-basiert in der Logging-Tabelle und transportiert sie per RFC oder DB-Verbindung, mit Latenzen unter fünf Sekunden. Das ist der Goldstandard für Real-Time-Replikation von Rohtabellen, besonders wenn SAP-Semantik nicht relevant ist und Tabellenänderungen direkt in den Bronze-Layer des Lakehouse fließen sollen.

Das Operational Data Provisioning (ODP) Framework ist die richtige Wahl, wenn SAP-Semantik erhalten bleiben muss. Durch die Aktivierung delta-fähiger CDS Views in der Operational Delta Queue (ODQ) bleibt die transaktionale Genauigkeit von der Quelle bis zum Ziel erhalten. ODP-Extraktion kann komplex werden: SAP hat bestimmte ODP-Pfade eingeschränkt, weshalb teilweise Middleware oder SAP Datasphere Replication Flows als Brücke zum Cloud-Storage nötig sind.

OData eignet sich, wenn Compliance und Audit-Nachvollziehbarkeit Priorität haben: jeder API-Call ist einzeln protokollierbar. JDBC (SparkJDBC) dagegen ist das Mittel der Wahl für schnelle Full Loads direkt aus On-Premise-HANA-Datenbanken, bietet aber kein natives Change Data Capture.

Wer die Komplexität von SLT-Konfiguration und ODP-Pfaden nicht selbst managen will, findet in Fivetran eine Alternative: eine vollständig verwaltete Data Movement Platform, die SAP-Daten über RFC-Konnektoren in Delta Lake extrahiert, mit integriertem CDC, automatischem Schema Handling und ohne eigene Middleware-Infrastruktur. Fivetran abstrahiert die Protokollebene und eignet sich besonders für Teams, die SAP-Extraktion neben 700+ weiteren Konnektoren als einheitliche Pipeline betreiben wollen.

Eine der technisch anspruchsvollsten Aufgaben bei der BW-Migration ist die Transformation jahrzehntealter ABAP-Logik in moderne Strukturen. Der strategische Paradigmenwechsel: es geht nicht mehr um das Verschieben von Tabellen, sondern um das Ausliefern von Data Products.

Ein Data Product ist ein kuratierter, business-freundlicher Datensatz (etwa "Order-to-Cash" oder "Global Inventory"), der den reichen Geschäftskontext und die semantischen Definitionen aus SAP-Systemen mitbringt. Der BDC Data Product Generator konvertiert BW-Objekte in Delta-Tabellen, die Databricks live abfragen kann. SAPs Zugriffskontrollen und semantische Schichten bleiben über Unity Catalog erhalten.

Nicht alles, was im BW liegt, muss migriert werden. Eine automatisierte Analyse ungenutzter BW-Assets kann den Migrationsumfang um bis zu 50% reduzieren. Das senkt nicht nur die Projektkosten, sondern reduziert auch die Komplexität der Zielarchitektur. Weniger Legacy-Ballast bedeutet eine schlankere, wartbarere Plattform, und ein Team, das sich auf die wirklich geschäftskritischen Datenprodukte konzentrieren kann.

Governance ist bei der SAP-BW-Migration kein Nachgedanke. Sie ist eine End-to-End-Anforderung, die von Tag eins mitgedacht werden muss. Wer SAP-Daten in ein Lakehouse überführt, muss sicherstellen, dass Zugriffskontrollen, Lineage und Compliance-Anforderungen auch in der neuen Welt durchgesetzt werden.

Unity Catalog ist Databricks zentralisierte Governance-Lösung, die weit über reine Tabellenverwaltung hinausgeht. Notebooks, ML-Modelle und die Lineage von AI-Assets werden zentral getrackt und mit feingranularen Zugriffskontrollen versehen. Databricks wurde als Leader im 2025 Gartner Magic Quadrant für Cloud Database Management Systems ausgezeichnet, ein starker Indikator für die Reife der Governance-Fähigkeiten der Plattform.

Die Integration zwischen SAP BDC und Databricks sichert Compliance durch mehrere Mechanismen: Mutual TLS und OAuth für sichere Token-basierte Vertrauensbeziehungen, Single Sign-On für synchronisierte Identitäten und Fine-Grained Auditing für PII-Maskierung nach regulatorischen Anforderungen. Besonders relevant für DSGVO-konforme Organisationen: SAP hat die Egress-Gebühren für Daten gestrichen, die über das Delta-Sharing-Protokoll geteilt werden, ein strategischer Schritt, der Multi-Cloud-Strategien deutlich wirtschaftlicher macht.

Für Unternehmen in hochregulierten Branchen bietet die "Secure Open Sharing with OIDC Token Federation" (seit Mitte 2025 allgemein verfügbar) die Möglichkeit, Daten mit Drittpartnern sicher auszutauschen, ohne physische Duplikation. Das erfüllt die Anforderungen der DSGVO, ohne die Architektur unnötig zu verkomplizieren.

Die Technologie ist verfügbar. Die Stolpersteine liegen in der Umsetzung. Drei Failure Modes sehen wir bei SAP-BW-Migrationen besonders häufig.

Ein verbreitetes Anti-Pattern: Teams versuchen, die Legacy-"View-on-View"-Kaskaden aus dem BW direkt im Lakehouse nachzubauen. Das Ergebnis sind verschachtelte Views, die bei jeder Query die gesamte Kette durchlaufen, mit exponentiell steigenden Compile- und Laufzeitkosten. Die Lösung ist konsequentes Materialisieren: schwere Joins und hochfrequent genutzte Datasets gehören in den Silver- oder Gold-Layer der Medallion Architecture. Views bleiben nur für leichtgewichtige semantische Präsentation.

Vertrauen in die neue Plattform entsteht nicht durch einen Big-Bang-Cutover, sondern durch rigorose Validierung. Lasst das Legacy-BW-System parallel weiterlaufen und validiert Domain für Domain:

Reconciliation: Vergleicht Mart-Outputs gegen BW-Query-Outputs für YTD-Summen und organisatorische Rollups.

Hierarchie-Integrität: Stellt sicher, dass Rollups nach Version und Datum in der neuen Plattform korrekt funktionieren.

Automatisierte Data-Quality-Checks: Implementiert kontinuierliche Qualitätsprüfungen, nicht periodische Audits, um Schema Drift und Volumenanomalien in Echtzeit zu erkennen.

Schema Drift ist das stille Risiko jeder Migration: Quellsysteme ändern sich, Felder werden hinzugefügt oder umbenannt, Datentypen verschieben sich. Ohne automatisierte Detection läuft die Pipeline weiter, mit falschen Daten. Die Lösung: Data-Quality-Automation als First-Class-Citizen der Plattform. Jede Ingestion-Pipeline braucht Schema-Validierung, Volumen-Checks und Anomalie-Erkennung, nicht als nachgelagertes Audit, sondern als integraler Bestandteil des Lakehouse-Architektur-Blueprints.

Die Frage kommt bei jeder SAP-Migration auf den Tisch. Beide Plattformen haben ihre Berechtigung. Die Unterschiede liegen im Detail. Databricks spielt seine Stärken bei großvolumigen SAP-Transformationen, Streaming und ML-Workloads aus: Apache Spark und die Photon Engine sind für genau diese Szenarien gebaut. Unabhängige Benchmarks zeigen ETL-Kosten, die bei Petabyte-Szenarien bis zu 9x unter Snowflake liegen.

Snowflake bleibt die bevorzugte Wahl für Organisationen, die "Turnkey"-Compliance und breite BI-Concurrency mit minimalem Platform-Engineering-Aufwand priorisieren. Der wachsende Trend in 2026 ist ein "Fit-for-Purpose"-Hybridmodell, bei dem Databricks das schwere Data Engineering und AI übernimmt, während Snowflake für strukturierte Business Intelligence zuständig ist.

Die SAP-BW-Migration zu Databricks ist kein Infrastruktur-Umzug. Sie ist die Chance, eine statische Reporting-Landschaft in ein dynamisches System of Intelligence zu transformieren, mit offenen Formaten, entkoppeltem Compute und AI-Readiness von Tag eins.

Die wichtigsten Takeaways:

Die Deadline steht: BW 7.5 Mainstream-Maintenance endet Dezember 2027. Eine BDC-Migration sichert Support bis 2030 beziehungsweise 2040.

Drei Pfade, ein Ziel: Brownfield für schrittweise Evolution, Greenfield für maximale Modernisierung, Hybrid für heterogene Landschaften. Der richtige Pfad hängt von eurer Legacy-Tiefe und eurem Zeithorizont ab.

Data Products statt Tabellen: ABAP-Logik nicht nachbauen, sondern in kuratierte Data Products transformieren, mit bis zu 50% weniger Migrationsumfang durch Unused-Asset-Analyse.

Governance von Anfang an: Unity Catalog, Delta Sharing und DSGVO-konforme Compliance sind keine Nachgedanken, sondern architektonische Grundpfeiler.

Fehler kennen heißt Fehler vermeiden: Die View Stack Trap, fehlende Validierung und Schema Drift sind die häufigsten Ursachen für gescheiterte Migrationen.

Die Mainstream-Maintenance für SAP BW 7.5 endet im Dezember 2027. Danach gibt es keine funktionalen Updates und keinen regulären Support mehr. Wer in die SAP Business Data Cloud (BDC) migriert, erhält verlängerten Support: bis 2030 für BW PCE und bis 2040 für BPC/4HANA.

SAP Databricks ist eine OEM-Version, die tief in das BDC-Ökosystem integriert ist. Sie bietet Serverless-Compute ohne DevOps-Aufwand, verzichtet aber auf Features wie Delta Live Tables, Auto Loader und offenes Data Sharing. Native Databricks ist die vollständige PaaS-Plattform mit dem kompletten Feature-Set, inklusive agentic AI, AI/BI Genie und offenem OIDC-Sharing.

Das hängt vom Use Case ab. SLT liefert Real-Time CDC mit unter fünf Sekunden Latenz, ideal für Rohtabellen-Replikation. ODP/ODQ erhält SAP-Business-Logik und Extraktoren, benötigt aber mehr Konfigurationsaufwand. OData eignet sich für Compliance-kritische Szenarien, JDBC für schnelle Full Loads aus On-Premise-HANA.

BDC ist SAPs "Suite as a Service"-Plattform, die SAP Datasphere, SAP Analytics Cloud und SAP Databricks auf einer gemeinsamen Architektur vereint. Daten werden im offenen Delta-Lake-Format auf Cloud Object Storage gespeichert und über Delta Sharing ohne Kopie zwischen SAP und Databricks geteilt.

Das variiert stark nach Pfad und Scope. Ein Brownfield-Proof-of-Concept steht typischerweise in zwei bis vier Monaten. Eine vollständige Greenfield-Migration mit ABAP-Transformation erstreckt sich auf 12 bis 18 Monate. Entscheidend: eine Unused-Asset-Analyse zu Beginn kann den Migrationsumfang um bis zu 50% senken und damit den Zeithorizont erheblich verkürzen.

Ja. Das Delta-Sharing-Protokoll ermöglicht Zero-Copy-Zugriff: Databricks fragt SAP-Daten direkt am Speicherort ab, ohne physische Replikation. SAP hat die Egress-Kosten für Delta Sharing gestrichen, wodurch diese Architektur wirtschaftlich besonders attraktiv wird.

Ein häufiges Anti-Pattern: Teams bauen die verschachtelten View-Ketten aus dem Legacy-BW im Lakehouse nach. Das führt zu exponentiell steigenden Query-Kosten, weil jede Abfrage die gesamte View-Kaskade durchlaufen muss. Die Lösung: schwere Joins und hochfrequent genutzte Datasets in der Medallion Architecture materialisieren. Views ausschließlich für leichtgewichtige semantische Schichten einsetzen.

Databricks eignet sich für massive Datentransformationen, Streaming und AI/ML-Workloads, mit ETL-Kosten, die bei Petabyte-Szenarien bis zu 9x niedriger liegen als bei Snowflake. Snowflake ist stärker bei Turnkey-BI und breiter SQL-Concurrency. Der Trend in 2026 geht zum Hybrid-Modell: Databricks für Engineering und AI, Snowflake für strukturierte BI.