Databricks gegen Snowflake: Architektur, Kosten und Anwendungsfälle

Databricks und Snowflake werden häufig verglichen, doch sie sind keine unmittelbaren Wettbewerber, die dasselbe Problem lösen. Databricks ist eine Lakehouse-Plattform, gebaut für Data Engineering, maschinelles Lernen und Analyse in mehreren Sprachen auf offenen Formaten. Snowflake ist ein Data Warehouse in der Cloud, optimiert für SQL-Analyse, hohe Gleichzeitigkeit und einen Betrieb ohne Administration. Viele Unternehmen fahren beides, Databricks für Umformung und maschinelles Lernen, Snowflake für die Auslieferung über SQL und für Data Sharing.

Die richtige Wahl hängt an drei Dingen: an Ihrer Hauptarbeitslast (ML-lastig gegen SQL-lastig), am Fähigkeitsprofil Ihres Teams (Python und Spark gegen SQL) und an Ihren bestehenden Investitionen in eine Cloud. Dieser Artikel vergleicht die beiden bei Architektur, Leistung, Kosten und Governance, damit Sie entscheiden können, oder damit Sie eine Strategie mit zwei Plattformen entwerfen können.

Architektur: Lakehouse gegen Cloud-Data-Warehouse

Der architektonische Unterschied ist grundlegend und treibt jede nachgelagerte Abwägung.

Databricks legt Daten in offenen Formaten (Parquet und Delta) in Ihrem Cloud-Speicher ab, also auf S3, ADLS oder GCS. Das Speicherkonto gehört Ihnen und Sie kontrollieren es. Delta Lake ergänzt diese Dateien um ACID-Transaktionen, die Durchsetzung von Schemata und Time Travel. Die Rechenleistung (Spark-Cluster) ist vom Speicher getrennt und skaliert unabhängig. Das Lakehouse behandelt strukturierte, halbstrukturierte und unstrukturierte Daten im selben System.

Snowflake legt Standardtabellen in einem eigenen spaltenbasierten Format ab, das vollständig von Snowflake verwaltet wird, und auf die darunterliegenden Dateien greifen Sie nicht unmittelbar zu. Die Ausnahme sind Iceberg-Tabellen von Snowflake: Sie nutzen das offene Format Apache Iceberg, auf Wunsch in kundenverwaltetem Speicher. Die Rechenleistung (virtuelle Warehouses) ist ebenfalls vom Speicher getrennt, doch Snowflake verwaltet beide Seiten: Sie konfigurieren die Größe eines Warehouse, nicht einzelne virtuelle Maschinen. Dieser verwaltete Ansatz tauscht Kontrolle gegen Einfachheit, denn es gibt keine Konfiguration von Clustern, keine Auswahl von Instanztypen und keine Infrastruktur zu pflegen.

Praktisch bedeutet das: Mit Databricks haben Sie volle Kontrolle über Ihre Datendateien und können sie mit jeder Maschine lesen (Spark, Presto, Trino, DuckDB). Mit Snowflake liegen Standardtabellen innerhalb der verwalteten Umgebung von Snowflake, einfacher zu betreiben, aber weniger übertragbar, sofern Sie keine Iceberg-Tabellen nutzen.

Wo jede Plattform gewinnt

Databricks gewinnt bei aufwendigem ETL und Data Engineering. Nehmen Sie ein hypothetisches Finanztechnologieunternehmen, das täglich 500 Millionen Transaktionen durch mehrstufige Anreicherung, Entdopplung und Betrugsbewertung schickt. Es würde Databricks nutzen, weil Spark die verteilte Berechnung von Haus aus beherrscht, und Lakeflow-Pipelines (früher Delta Live Tables) steuern die Orchestrierung der Pipeline. Dieselbe Pipeline kann sowohl ein Modell zur Betrugsbewertung in Echtzeit als auch eine Berichtsschicht im Stapelbetrieb speisen, ohne eigene Infrastruktur für Datenströme.

Databricks gewinnt bei Arbeitslasten für ML und KI. Ein Einzelhändler, der Modelle zur Nachfrageprognose trainiert, braucht Feature Engineering, das Verfolgen von Experimenten und das Ausliefern von Modellen an einem Ort. Databricks liefert MLflow, GPU-Cluster und unmittelbaren Zugriff auf die Trainingsdaten im Delta Lake, ohne sie in eine getrennte ML-Umgebung zu exportieren. Die Daten verlassen die Plattform nie.

Snowflake gewinnt bei SQL-Analyse und BI. Ein hypothetisches Medienunternehmen mit 200 Analysten, die nach Bedarf Abfragen gegen Nutzungsdaten fahren, braucht schnellen, gleichzeitigen Zugriff über SQL. Die Multi-Cluster-Warehouses von Snowflake (ab der Enterprise Edition) starten automatisch zusätzliche Rechenleistung, wenn 50 Nutzer gleichzeitig abfragen, ohne dass Clustergrößen konfiguriert oder Konflikte um Ressourcen bedacht werden müssen.

Snowflake gewinnt beim Data Sharing. Ein Anbieter von Gesundheitsdaten, der anonymisierte Datensätze an Forschungseinrichtungen veröffentlicht, nutzt Secure Data Sharing von Snowflake. Abnehmer greifen über ihre eigenen Snowflake-Konten auf Live-Daten zu, ohne dass Daten bewegt, Dateien übertragen oder API angebunden werden; es werden keine Daten kopiert. Abnehmer ohne Snowflake-Konto nutzen Reader Accounts, die der Anbieter einrichtet und bezahlt, und direkte Freigaben funktionieren innerhalb derselben Region (andere Regionen erfordern eine Replikation). Der Marketplace von Snowflake erweitert das auf die Monetarisierung von Daten Dritter.

Snowflake gewinnt bei der Einfachheit ohne Administration. Ein Unternehmen mit kleinem Datenteam und ohne eigene Plattformtechnik profitiert vom verwalteten Ansatz von Snowflake. Es gibt keine Cluster zu konfigurieren, keine Instanztypen zu wählen und keine Regeln für automatische Skalierung abzustimmen. Das Team schreibt SQL, und Snowflake erledigt den Rest.

Leistung: was die Vergleichstests zeigen

Aussagen zur Leistung ohne Zusammenhang sind bedeutungslos. Beide Plattformen sind schnell, die Frage ist, schnell bei was.

ETL im großen Maßstab und aufwendige Umformungen: Databricks gewinnt. Die verteilte Ausführungsmaschine von Spark, die Beschleunigung durch Photon und die Optimierungen von Delta Lake (Z-Ordering, das Überspringen von Daten) bringen bei Umformungen über mehrere Terabyte messbare Vorteile. Ein hypothetischer ETL-Job, der fünf Tabellen mit insgesamt 2 TB verknüpft, lässt sich zum Beispiel über Dutzende Knoten verteilen, weil Spark von Haus aus parallelisiert.

Gleichzeitige SQL-Abfragen nach Bedarf: Snowflake gewinnt. Wenn 100 Nutzer gleichzeitig Abfragen abschicken, skalieren die Multi-Cluster-Warehouses von Snowflake (ab der Enterprise Edition) die Rechenleistung automatisch, ohne Abfragen in eine Warteschlange zu stellen. Databricks SQL hat sich mit serverlosen Warehouses deutlich verbessert, doch der Umgang mit Gleichzeitigkeit bleibt bei Snowflake für BI-Arbeitslasten mit vielen Menschen ausgereifter.

Training von ML-Modellen: Databricks bietet mehr Tiefe. Spark ML, die Unterstützung von GPU-Clustern und die eingebaute Anbindung an TensorFlow, PyTorch und scikit-learn machen es zur etablierten Wahl. Snowflake ML bietet inzwischen einen Feature Store, eine Model Registry, eine GPU-Container-Runtime und Model Serving; Databricks hat die länger etablierte ML-Plattform (MLflow, Mosaic AI).

Latenz bei Datenströmen: Databricks gewinnt. In Spark Structured Streaming sind Micro-Batches typischerweise in Sekunden abgeschlossen, und der Real-Time-Modus zielt auf Millisekunden. Snowpipe von Snowflake lädt Dateien mit Latenzen im Minutenbereich, während Snowpipe Streaming eine Latenz von der Aufnahme bis zur Abfrage ab 5 Sekunden erreicht, geeignet für Analyse nahezu in Echtzeit, aber nicht für die Verarbeitung von Ereignissen im Millisekundenbereich.

Vergleich der Kosten

Die Kostenstrukturen sind grundlegend verschieden, und dieser Unterschied verwirrt die meisten Vergleiche.

Databricks: zwei Rechnungen. Databricks berechnet Rechenleistung in DBU. Bei Classic Compute berechnet Ihr Cloud-Anbieter (AWS, Azure, GCP) getrennt virtuelle Maschinen, Speicher und ausgehenden Datenverkehr, die Gesamtkosten sind also DBU-Gebühren plus Cloud-Infrastruktur; bei Serverless ist die Infrastruktur im DBU-Satz enthalten. Das gibt Ihnen Kontrolle über die Auswahl der Instanzen und die Speicherstufen, erschwert aber die Planung. Ausführliche Aufschlüsselungen stehen im Leitfaden zu den Preisen von Databricks.

Snowflake: eine Rechnung. Snowflake berechnet Credits, die die Rechenleistung abdecken, und der Speicher wird getrennt zu einem festen Satz je TB abgerechnet. Es gibt keine eigene Rechnung für Cloud-Infrastruktur, Snowflake verwaltet sie intern. Das macht die Kostenschätzung einfacher, verringert aber Ihre Möglichkeit, die Infrastruktur eigenständig zu optimieren.

Bei vergleichbaren Arbeitslasten für SQL-Analyse, etwa einem Team aus 20 Analysten, das während der Geschäftszeiten Abfragen fährt, ist Snowflake oft wirtschaftlicher, wegen des automatischen Pausierens, des automatischen Fortsetzens und der Abrechnung im Sekundentakt (mit einem Minimum von 60 Sekunden bei jedem Start eines Warehouse). Bei Arbeitslasten für Data Engineering und maschinelles Lernen kann Databricks günstiger sein, weil Jobs Compute niedrigere DBU-Sätze nutzt und Spot-Instanzen die Kosten für virtuelle Maschinen um bis zu 90 % senken können, je nach Instanz.

Die ehrliche Antwort: Keines von beiden ist grundsätzlich günstiger. Die Kosten hängen von der Mischung der Arbeitslasten ab, von der Disziplin beim Führen der Cluster und davon, ob Sie Rabatte für Abnahmezusagen nutzen. Unternehmen, die ihre Databricks-Cluster nicht aktiv führen, zahlen zu viel. Unternehmen, die ihre Snowflake-Warehouses überdimensionieren, zahlen zu viel.

Governance und Kontrolle über Daten

Der Databricks Unity Catalog steuert Tabellen, Sichten, ML-Modelle und Dateien innerhalb von Databricks. Er bietet feingranulare Zugriffskontrolle (auf Ebene von Tabelle, Spalte und Zeile), automatische Verfolgung der Lineage und Prüfprotokolle. Der entscheidende Punkt: Ihre Daten liegen in Ihrem eigenen Cloud-Speicherkonto. Das zählt für Datensouveränität, für regulatorische Compliance und für den Zugriff mit mehreren Werkzeugen, denn andere Maschinen können dieselben Delta-Dateien unmittelbar lesen.

Die Governance von Snowflake, gebündelt unter Snowflake Horizon, umfasst Zugriffsrichtlinien, Maskierungsrichtlinien, Richtlinien für den Zugriff auf Zeilen, das Kennzeichnen von Objekten, die Klassifizierung sensibler Daten, den Zugriffsverlauf (Access History), Lineage und Funktionen für Metriken der Datenqualität. Maskierung, Richtlinien für den Zugriff auf Zeilen, Klassifizierung, Access History, Lineage und die Überwachung der Datenqualität setzen die Enterprise Edition oder höher voraus. Die Governance wirkt innerhalb der verwalteten Umgebung von Snowflake. Secure Data Sharing von Snowflake erlaubt den Zugriff auf Daten über Organisationsgrenzen hinweg, ohne Daten zu bewegen. Die Entsprechung bei Databricks ist OpenSharing (früher Delta Sharing), ein offenes Protokoll, das Bestände aus Unity Catalog mit Empfängern innerhalb und außerhalb von Databricks teilt und die Grundlage von Databricks Marketplace und Clean Rooms bildet.

Für Unternehmen, die beide Plattformen betreiben, deckt die Governance keines der beiden Anbieter das ganze Bild ab. Unity Catalog kann Snowflake-Daten über Lakehouse Federation als Foreign Catalogs abfragen und steuern, doch jeder native Katalog ist auf seine eigene Plattform ausgerichtet. Hier liefert ein plattformübergreifender Datenkatalog wie Dawiso einheitliche Sichtbarkeit, durchgängige Data Governance und Lineage von Ende zu Ende über beide Plattformen.

Wann beides zu betreiben ist

Das Muster „Lakehouse plus Warehouse“ wird immer verbreiteter. Unternehmen nutzen Databricks für Aufnahme, Umformung und das Training von Modellen und schieben dann kuratierte Datensätze nach Snowflake für die Auslieferung über SQL und für Data Sharing. Das ist kein Anti-Muster, es spielt die Stärken beider Plattformen aus.

Eine typische Architektur mit zwei Plattformen: Rohdaten aus den Quellsystemen landen in Databricks. dbt formt sie zu sauberen, modellierten Tabellen im Delta Lake. Ein Teil dieser Tabellen, nämlich die, die Analysten und BI-Werkzeuge am häufigsten abfragen, wird nach Snowflake gespiegelt, wo zum Beispiel 200 gleichzeitige Nutzer Abfragen nach Bedarf fahren, ohne mit technischen Arbeitslasten zu konkurrieren. ML-Modelle trainieren weiterhin gegen den vollständigen Delta Lake in Databricks.

Die Aufgabe der Governance in einem Aufbau mit zwei Plattformen ist real: zwei Kataloge, zwei Berechtigungsmodelle, zwei Systeme für Lineage. Dawiso überbrückt diese Lücke, indem es Metadaten aus beiden Plattformen aufnimmt und einen einzigen durchsuchbaren Katalog, ein einheitliches Business Glossary und plattformübergreifende Lineage bietet. Sobald die Verknüpfungen zwischen den Plattformen bestehen, kann eine Analystin eine Sicht in Snowflake durch die Umformungspipeline in Databricks bis zum ursprünglichen Quellsystem zurückverfolgen, in einem einzigen Graphen der Lineage. Diese plattformübergreifenden Verknüpfungen entstehen nicht automatisch: Sie stammen aus dem Parsen von SQL, aus dbt oder aus manuell angelegten Beziehungen, und der Snowflake-Konnektor liefert keine native Lineage von Spalte zu Spalte.

Rahmen für die Entscheidung

Die Wahl zwischen Databricks und Snowflake geht nicht darum, was „besser“ ist, sondern darum, was zu Ihrer Hauptarbeitslast, Ihrem Team und Ihrer Architektur passt.

Wenn 70 % Ihres Teams SQL schreibt und Ihr Hauptergebnis Dashboards und Berichte sind, beginnen Sie mit Snowflake. Die Lernkurve ist flach, der Aufwand für Administration nahe null, und der Umgang mit Gleichzeitigkeit ist für BI-Arbeitslasten der beste am Markt. Databricks können Sie später für maschinelles Lernen oder aufwendige Technik ergänzen, wenn der Bedarf entsteht.

Wenn Ihre Hauptarbeitslast Datenpipelines und das Training von ML-Modellen ist, beginnen Sie mit Databricks. Umformung auf Basis von Spark, MLflow und die Lakehouse-Architektur sind eigens dafür gebaut. Databricks SQL deckt Ihren Bedarf an Analyse ohne eine zweite Plattform, auch wenn es die Gleichzeitigkeit von Snowflake bei BI-Szenarien mit sehr vielen Nutzern nicht erreicht.

Wenn Sie beides brauchen, schwere Technik und ML sowie Auslieferung über SQL mit hoher Gleichzeitigkeit, erwägen Sie, beides zu betreiben. Databricks für Umformung und maschinelles Lernen, Snowflake für den Verbrauch über SQL. Das ist die teuerste Variante, zwingt aber keine der Plattformen in ihre Schwäche.

Wenn Kontrolle über das Datenformat und Übertragbarkeit zählen, neigen Sie zu Databricks. Offene Formate bedeuten, dass Sie die Rechenmaschine wechseln können, ohne Daten zu migrieren. Das eigene Format von Snowflake für Standardtabellen optimiert die Leistung, bindet diese Daten aber an die Plattform. Iceberg-Tabellen von Snowflake nutzen das offene Format Apache Iceberg, auf Wunsch in kundenverwaltetem Speicher, und verkleinern so den Abstand.

Wenn das Teilen von Daten mit externen Partnern wichtig ist, haben beide Plattformen eine ausgereifte Antwort. Snowflake bietet Secure Data Sharing und den Marketplace, mit vom Anbieter bezahlten Reader Accounts für Abnehmer außerhalb von Snowflake. Die Entsprechung bei Databricks ist OpenSharing (früher Delta Sharing), ein offenes Protokoll, das Bestände aus Unity Catalog mit Empfängern innerhalb und außerhalb von Databricks teilt und die Grundlage von Databricks Marketplace und Clean Rooms bildet.

Wie Dawiso beide Plattformen steuert

Ob Sie Databricks, Snowflake oder beides wählen, Governance auf Ebene der Plattform genügt nicht. Unity Catalog steuert die Bestände in Databricks. Die Governance von Snowflake deckt Objekte in Snowflake ab. Jede ist auf ihre eigene Plattform ausgerichtet, und keine erfasst die SaaS-Werkzeuge, BI-Plattformen und Altdatenbanken, die Ihren Datenstapel vervollständigen.

Der Datenkatalog von Dawiso nimmt Metadaten über seine Konnektoren für Databricks und Snowflake sowohl aus dem Databricks Unity Catalog als auch aus den Informationsschemata von Snowflake auf. Teams suchen Datensätze an einer Stelle: „Wo liegt unsere kanonische Umsatzkennzahl?“ liefert Ergebnisse unabhängig von der Plattform. Die Lineage in Dawiso kann die ganze Pipeline umspannen, von der Quelldatenbank über die Umformung in Databricks und die Auslieferungsschicht in Snowflake bis zum Bericht in Power BI, den eine Führungskraft liest. Die Verknüpfungen zwischen den Plattformen stammen aus dem Parsen von SQL, aus dbt oder aus manuellen Beziehungen und entstehen nicht automatisch.

Das Business Glossary in Dawiso sorgt dafür, dass „monatlich wiederkehrender Umsatz“ oder „aktiver Nutzer“ auf beiden Plattformen dasselbe bedeutet. Ohne ein gemeinsames Glossar erzeugen Teams, die in Databricks bauen, und Teams, die in Snowflake abfragen, auseinanderlaufende Definitionen, ein Problem, das sich mit dem Wachstum des Unternehmens verstärkt.

Über das Model Context Protocol (MCP) können KI-Agenten mit dem Dawiso MCP-Server den Katalog durchsuchen, die Lineage verfolgen und Objekte sowie Datenstichproben über beide Plattformen hinweg ansehen, über eine einheitliche Schnittstelle.

Fazit

Databricks und Snowflake lösen verschiedene Probleme gut. Databricks glänzt bei Data Engineering, maschinellem Lernen und einer Lakehouse-Architektur auf offenen Formaten. Snowflake glänzt bei SQL-Analyse, Gleichzeitigkeit, Einfachheit und Data Sharing. Die Entscheidung hängt davon ab, welche Probleme Ihr Unternehmen zuerst lösen muss. Viele Teams kommen zum Schluss, dass die Antwort „beides“ lautet, und das ist eine gültige Architektur und kein Kompromiss. Entscheidend ist, den ganzen Stapel einheitlich zu steuern, und genau dort füllt ein plattformübergreifender Katalog wie Dawiso die Lücke, die keine der Plattformen allein abdeckt.

Quellen

• Snowflake Documentation - Apache Iceberg tables
• Snowflake Documentation - Understanding overall cost
• Snowflake Documentation - Multi-cluster warehouses
• Snowflake Documentation - Snowpipe Streaming overview
• Snowflake Documentation - Snowflake ML overview
• Snowflake Documentation - About Secure Data Sharing
• Snowflake Documentation - Data governance in Snowflake
• Databricks Documentation - Real-time mode in Structured Streaming
• Databricks Documentation - What is OpenSharing?
• Databricks Documentation - What is Lakehouse Federation?
• AWS - Amazon EC2 Spot Instances
• Dawiso Help - Snowflake connector
• Dawiso Help - Dawiso Model Context Protocol (MCP)
• Snowflake Documentation - Snowflake editions