Snowflake vs. Databricks: So treffen Sie die Plattformwahl

Wovon hängt die Wahl ab?

Beginnen Sie mit Ihrem Bestand: Welche Abfragen müssen unverändert richtige Ergebnisse liefern? Welche Pipelines und Bibliotheken sollen weiterlaufen? Wer betreibt die Plattform nach der Einführung? Ein Featurekatalog beantwortet diese Fragen nur teilweise. Die folgenden Prüfschritte machen Unterschiede für Ihr Team sichtbar und ergeben ein Entscheidungsblatt, das Sie später nachvollziehen können.

Was ist Snowflake?

Snowflake ist eine verwaltete Cloud-Datenplattform. Ihre Architektur trennt Datenhaltung, Rechenleistung und übergreifende Cloud Services. Ein Virtual Warehouse ist dabei eine Gruppe von Compute-Ressourcen für Abfragen und Verarbeitung. Mehrere Warehouses können eigene Rechenressourcen verwenden, während sie auf gemeinsame Daten zugreifen. Das erleichtert die getrennte Planung verschiedener Arbeitslasten; passende Größen und Laufzeiten müssen Sie trotzdem festlegen.

Zur Plattform gehören SQL, Data Engineering und Snowpark für Code in Python, Java und Scala. Hinzu kommen Funktionen für Machine Learning. Snowflake betreibt die zugrunde liegende Plattforminfrastruktur als Service. Ihr Team entscheidet weiterhin über Datenmodelle, Rollen, Transformationslogik und Betriebsregeln. Eine verwaltete Plattform nimmt Ihnen diese fachlichen Entscheidungen nicht ab. Die Snowflake-Architekturdokumentation beschreibt diese Trennung und den Funktionsumfang.

Was ist Databricks?

Databricks ist eine Daten- und KI-Plattform mit Lakehouse-Ansatz: Datenhaltung und Verarbeitung werden für Data Engineering, Analytics und Machine Learning zusammengeführt. Integrierte Bausteine sind unter anderem Apache Spark, Delta Lake und MLflow. Für SQL-Abfragen und BI stehen Databricks SQL und SQL-Warehouses bereit. Eine BI-Abfrage benötigt daher nicht automatisch eigenen Spark-Code.

Ihr Team kann mit SQL, Notebooks und Entwicklungswerkzeugen arbeiten und je nach Aufgabe Classic- oder Serverless-Compute einsetzen. Daten- und KI-Objekte werden über Unity Catalog verwaltet. Auch hier bleiben Datenmodell, Zugriffsentscheidungen, Pipelineverhalten und Betriebsverantwortung Aufgaben Ihres Teams. Entscheidend ist, welche dieser Arbeitsweisen Ihr Bestand benötigt und Ihre Mitarbeitenden sicher betreiben können. Die Databricks-Plattformübersicht ordnet die Komponenten ein; die SQL-Dokumentation beschreibt den Analytics-Bereich.

Welche Workloads müssen Sie wirklich abdecken?

Ersetzen Sie die Frage nach der „besseren Plattform“ durch repräsentative Aufgaben. Die Tabelle zeigt verfügbare Ansätze und die Abnahmefrage, die für beide gilt. Verfügbarkeit und Einschränkungen prüfen Sie anschließend für Ihre Cloud, Region und konkrete Konfiguration.

SQL und bestehende Pipelines

Nutzen Sie für BI einen kleinen Satz echter Abfragen: etwa einen regelmäßig aktualisierten Bericht, eine große Verknüpfung und eine interaktive Analyse. Legen Sie die erwarteten Ergebnisse vorher fest. Bei Pipelines zählen zusätzlich vorhandener Code, Tests und Debuggingwege. Snowflake dokumentiert Dynamic Tables sowie Streams und Tasks in seiner Funktionsübersicht; Databricks beschreibt Spark und Lakeflow in der Plattformübersicht.

Haben Sie Spark-Code, testen Sie dessen tatsächliche APIs und Bibliotheken. Snowpark Connect verwendet Snowflake als Ausführungsengine und dokumentiert Unterschiede gegenüber Spark. Der passende API-Name allein belegt deshalb keine unveränderte Ausführung Ihres Programms. Erfassen Sie notwendige Codeänderungen als Migrationsaufwand.

Prüfen Sie dabei auch die tägliche Entwicklungsarbeit. Lassen Sie dieselbe Person auf beiden Varianten eine Transformation ändern, einen Test ausführen und einen fehlgeschlagenen Lauf untersuchen. Notieren Sie benötigte Kenntnisse, zusätzliche Werkzeuge und offene Fragen. Ein fachlich funktionierender Job ist noch nicht betriebsfähig, wenn nur die Person aus dem Pilot ihn ändern oder wiederherstellen kann. Diese Probe ergänzt den Workloadvergleich um eine nachvollziehbare Teamübergabe.

Streaming und Machine Learning

Unterscheiden Sie die Aufnahme von Ereignissen von deren Verarbeitung. Snowpipe Streaming nimmt Zeilen in Snowflake- beziehungsweise Snowflake-verwaltete Iceberg-Tabellen auf. Zustandsbehaftete Aufgaben wie das Zusammenführen zeitlich versetzter Ereignisse brauchen eine eigene Umsetzung und Abnahme. Databricks setzt für Streaming unter anderem auf Spark Structured Streaming. Testen Sie für beide denselben fachlichen Ereignisfall einschließlich einer Doppelübertragung und einer verspäteten Korrektur.

Für ML reicht „Python verfügbar“ ebenfalls nicht. Snowflake ML unterstützt eigenes Modelltraining, CPU- und GPU-Compute, Experimente, Model Registry und Inferenz. Die Databricks-ML-Dokumentation beschreibt Entwicklung, Tracking, Registry, Serving und Monitoring. Führen Sie Ihr vorgesehenes Modell durch diesen Lebenszyklus: Datenzugriff, Training, nachvollziehbare Version, Freigabe, Bereitstellung und Beobachtung im Betrieb. Belegen Sie, an welcher Stelle zusätzliche Werkzeuge nötig sind.

Wie prüfen Sie Governance und Datenfreigabe?

Vergleichen Sie das Verhalten Ihrer Zugriffsregeln. Snowflake bietet neben Rollen und Objektberechtigungen Masking- und Row-Access-Policies für Spalten beziehungsweise Zeilen. Unity Catalog bündelt bei Databricks die Governance von Daten- und KI-Objekten, Zugriffsrechten, Lineage und Auditierung. Welche Funktionen Sie verwenden können, prüfen Sie jeweils mit den Voraussetzungen der konkreten Plattformkonfiguration.

Ein brauchbarer Testfall ist eine Auftragstabelle mit einer vertraulichen Kundenspalte und regional eingeschränktem Zugriff. Legen Sie eine Analystenidentität und eine privilegierte Betriebsidentität an. Prüfen Sie den erlaubten und den verbotenen Zugriff aus dem BI-Werkzeug, aus einem Notebook und über die vorgesehenen Schnittstellen. Bei einer externen Engine gehört auch dieser Zugriffspfad in den Test.

Dokumentieren Sie je Versuch Identität, Regel, erwartete Sicht, tatsächliches Ergebnis und Auditnachweis. Lassen Sie zusätzlich einen Mitarbeitenden nachvollziehen, aus welchen Quellen eine Kennzahl entstanden ist. Damit werden Rechte und Lineage überprüfbar. Benötigen Sie Datenfreigaben an andere Teams oder Organisationen, ergänzen Sie Empfänger, Identitätsverwaltung, Widerruf und zulässige Weiterverarbeitung. Ein Governance-Feature in der Produktliste ersetzt diese Abnahme nicht.

Was bedeuten offene Formate für Ihre Bindung?

Ein offenes Tabellenformat kann den Zugriff durch mehrere Engines ermöglichen. Daraus folgt noch keine vollständige Wechselbarkeit Ihrer Datenplattform. Prüfen Sie drei Ebenen getrennt: Dateien und Tabellenformat, Katalog und Rechte sowie die darauf aufgebauten Dienste und Betriebsabläufe.

Snowflake unterstützt neben nativen Tabellen Apache-Iceberg-Tabellen mit unterschiedlichen Katalog- und Storageoptionen. Für Snowflake-verwaltete Iceberg-Tabellen ist auch Zugriff durch externe Iceberg-REST-kompatible Engines dokumentiert. Prüfen Sie die jeweils unterstützten Operationen und Voraussetzungen, statt alle Tabellen eines Accounts als gleich portabel zu behandeln.

Databricks unterstützt verwaltete und externe, sogenannte foreign Iceberg-Tabellen. Foreign-Tabellen sind laut Dokumentation nur lesbar und eingeschränkt integriert. Unity-Catalog-verwaltete Iceberg-Tabellen können externe Lese- und Schreibzugriffe über die Iceberg REST Catalog API erlauben; dafür gelten dokumentierte Voraussetzungen. Auch hier müssen Tabellentyp, Katalog und Zugriffspfad zusammenpassen.

Für Ihren Portabilitätstest lesen Sie eine ausgewählte Tabelle mit der vorgesehenen zweiten Engine und prüfen Ergebnis und Berechtigungen. Falls Schreiben ein Ziel ist, testen Sie zusätzlich eine Änderung und deren Sichtbarkeit. Inventarisieren Sie danach SQL-Dialekte, Pipelinecode, Modelle, Geschäftslogik und Monitoring. Unsere Schlussfolgerung daraus: Formatportabilität und die Übertragbarkeit dieser Dienste sind unterschiedliche Nachweise. Offene Dateien allein übertragen keine fachliche Semantik oder Betriebsverantwortung.

Welche Kosten gehören in die TCO-Rechnung?

Vergleichen Sie Kosten für dasselbe nutzbare Ergebnis über denselben Zeitraum. Ein Credit und eine DBU sind verschiedene Verbrauchseinheiten; ihre Anzahl ergibt für sich keine Rangfolge.

Die Snowflake-Kostenübersicht unterscheidet Compute, Storage und Data Transfer. Compute-Kosten ergeben sich aus Verbrauch und Creditpreis; besondere Dienste können eigene Verbrauchsmechaniken haben. Virtual Warehouses werden pro Sekunde mit mindestens 60 Sekunden je Start abgerechnet. Kurze, häufige Starts gehören deshalb in Ihren Lastversuch.

Eine Databricks Unit, kurz DBU, ist eine normalisierte Verbrauchseinheit. Für Classic-Compute berücksichtigt die Databricks-Kostendokumentation zusätzlich VM-, Disk- und Netzwerkkosten. Bei Serverless ist VM-Compute bereits im DBU-Preis enthalten. Addieren Sie ihn dort nicht erneut; prüfen Sie die übrigen Speicher- und Transferkosten anhand des jeweiligen Leistungsumfangs und Ihrer Cloudrechnung.

Als redaktionelle Vergleichsmethode empfehlen wir: TCO = laufender Plattform- und Infrastrukturverbrauch + Betriebsaufwand + Einführung und Änderungen, jeweils im selben Betrachtungszeitraum. Kennzeichnen Sie gemessene Werte, Vertragswerte und Schätzungen getrennt. Rechnen Sie ein normales und ein erhöhtes Lastszenario durch. Dann zeigt Ihr Blatt, welche Annahme die Entscheidung verändert, statt aus einem einzelnen Listenpreis eine pauschale Ersparnis abzuleiten.

So bauen Sie einen fairen Pilot

Der folgende Versuchsaufbau ist eine Empfehlung für Ihre Entscheidung, kein veröffentlichter Performancebenchmark. Er hält die fachliche Aufgabe konstant und macht den Aufwand jeder Umsetzung sichtbar.

1. Aufgabe und Abnahme festlegen. Wählen Sie einen BI-Job, eine Pipeline und bei Bedarf Ihren ML- oder Streamingfall. Schreiben Sie Soll-Ergebnis, zulässige Aktualität und benötigte Zugriffsregeln vor der Umsetzung auf.
2. Gleiche Eingaben bereitstellen. Verwenden Sie dieselbe Datenversion und dieselbe fachliche Logik. Dokumentieren Sie Region, Compute-Konfiguration, Format, Optimierungen und notwendige Codeänderungen.
3. Repräsentative Last durchführen. Testen Sie Einzelabfragen und parallele Nutzer. Trennen Sie kalte und bereits aufgewärmte Läufe. Erfassen Sie Verarbeitung und Datenaufnahme bis zum sichtbaren Ergebnis.
4. Fehler und Übergabe prüfen. Spielen Sie ein ungültiges oder verspätetes Ereignis ein. Lassen Sie ein Teammitglied den Fehler finden, beheben und den Job erneut ausführen. Halten Sie Aufwand und offene Betriebsfragen fest.
5. Ergebnis und TCO gemeinsam bewerten. Übernehmen Sie Verbrauch, zusätzlichen Betrieb und Migration in das Kostenblatt. Entscheiden Sie anhand der vorher definierten Abnahme; kennzeichnen Sie ungeklärte Punkte ausdrücklich.

Ihr Ergebnisprotokoll braucht pro Aufgabe mindestens Datenversion, Plattformkonfiguration, Soll- und Ist-Ergebnis, Lastprofil, gemessene Zeit, Verbrauch, Änderungen und Owner. Ein schneller Lauf mit einer anderen Ergebnisdefinition ist kein vergleichbarer Lauf. Fehlt ein belastbarer Beleg, planen Sie einen gezielten Folgetest. Ein offener Befund ist hilfreicher als eine unbegründete Siegerwertung.

Wie Sie aus Befunden eine Entscheidung machen

Trennen Sie zwingende Anforderungen von abwägbaren Vorteilen. Richtige fachliche Ergebnisse, benötigte Zugriffsbeschränkungen und ein betreibbarer Fehlerweg können beispielsweise zwingende Kriterien sein. Legen Sie diese Einordnung gemeinsam mit Fachbereich und Betrieb vor dem Versuch fest. Eine kürzere Antwortzeit sollte einen fehlenden Pflichtnachweis nicht verdecken.

Für die verbleibenden Kriterien dokumentieren Sie Priorität und Begründung. Wenn vorhandener Code auf einer Variante mit weniger Änderungen funktioniert, ist das ein konkreter Befund zu Ihrem Bestand. Wenn die andere Variante Ihre Rechte- und Betriebsabnahme einfacher erfüllt, ist auch dieser Aufwand entscheidungsrelevant. Vergleichen Sie jeweils den vollständigen Pfad. Einzelne Messwerte aus unterschiedlich optimierten Konfigurationen reichen dafür nicht.

Halten Sie die Wahl als bedingte Entscheidung fest: gewählte Variante, erfüllte Pflichtkriterien, wichtigste Abwägung und Anlass für eine erneute Prüfung. Dieser Anlass kann ein neuer Workload, eine geänderte Zugriffsvorgabe oder ein wesentlich anderes Lastprofil sein. So bleibt der Pilot auch nach der Plattformwahl ein nutzbares Entscheidungsdokument.

Wann lohnt sich der Parallelbetrieb?

Zwei Plattformen können sinnvoll sein, wenn getrennte Nutzergruppen nachweislich unterschiedliche Anforderungen haben. Prüfen Sie vorher, ob ein einziges Betriebsmodell die Aufgaben mit vertretbarem Aufwand erfüllen kann. Zusätzliche Plattformen brauchen einen eigenen Nutzen im Entscheidungsblatt.

Falls Sie beide einsetzen, empfehlen wir für jedes wichtige Dataset eine führende Quelle und eine eindeutige Schreibverantwortung. Definieren Sie Aktualitätsziel, Übergabeformat, Zugriffsregeln und Störungszuständigkeit über die Grenze hinweg. Halten Sie fest, wer eine Änderung freigibt und wie abhängige Berichte informiert werden. Selbst wenn sich Daten ohne zusätzliche Dateikopie lesen lassen, bleiben diese Aufgaben bestehen. Nehmen Sie Rechtepflege, Abstimmung und Betrieb beider Plattformen in die TCO-Rechnung auf.

Der nächste Schritt nach dem Vergleich

Verdichten Sie den Pilot zu einer Entscheidung mit vier Anlagen: Anforderungen, Ergebnisprotokoll, Kostenblatt und Betriebsübergabe. Vermerken Sie Annahmen und verbleibende Risiken. So kann das Team die Wahl bei neuen Workloads erneut prüfen.

Wenn daraus ein konkreter Snowflake-Umsetzungspfad entsteht, finden Sie auf der Snowflake-Partnerseite von eBiz den bestehenden Rahmen für Architektur, Migration, Governance und Kostensteuerung. Bringen Sie die erarbeiteten Kriterien und Pilotbefunde mit; sie machen die anschließende Planung konkret.