Snowflake vs. Databricks: Der große Showdown

Die Daten

Unser Benchmark nutzt den TPC-H Scale Factor 1000. Dieser Datensatz umfasst rund 6 Milliarden Zeilen in der größten Tabelle. Sowohl Snowflake als auch Databricks bringen TPC-H-Daten mit, allerdings weder in identischen Größen noch mit exakt denselben großen Datensätzen. Für einen echten Apples-to-Apples-Vergleich muss man die Daten per ETL von Snowflake nach Databricks bringen. Am einfachsten geht das mit einem darauf zugeschnittenen Tool wie Estuary – oder Sie erledigen es selbst.

Databricks liefert mit:

• tpcds_sf1 und sf1000
• tpch mit 30 Millionen Zeilen. Das ist etwa die Hälfte von Snowflakes Scale Factor 10, der 60 Millionen Zeilen umfasst.

Snowflake liefert mit:

• tpcds_sf10 und 100
• tpch in den Scale Factors 1, 10, 100 und 1000

Wenig überraschend: Die Plattformen machen es einem nicht leicht, Performance zu vergleichen, indem sie keine vergleichbaren Sample-Daten bereitstellen. 🤨

Szenarien

Wir haben die vorhandenen Standard-Queries in 3 Szenarien verwendet:

• Alle 22 Queries sequenziell ausführen. Hier ist nur Query 1 ein Cold Start; jede folgende Query kann vom Warehouse-Cache der vorherigen Queries profitieren.
• Alle 22 Queries gleichzeitig ausführen. Damit prüfen wir, wie gut die Datenplattform mehrere Queries parallel verarbeitet und ob horizontale Skalierung sichtbar wird.
• 5 Cold-Start-Queries. Wir haben eine kleine Auswahl an Queries mit unterschiedlicher Komplexität und unterschiedlichem Stil ausgeführt, um die Plattformen auf einem kalten Warehouse zu vergleichen.

CTAS-Workloads: Da die Standard-Benchmark-Queries eher kleine, stark aggregierte Ergebnisse liefern, eignen sie sich nicht gut, um reale CTAS-Workloads abzubilden – der Schreib-Payload wäre schlicht zu klein, um den Schreibdurchsatz an die Belastungsgrenze zu bringen. Für schreibintensive Operationen haben wir daher 5 Varianten gebaut, die große Ergebnismengen mit unterschiedlichen Datenformen materialisieren – von schmalen Tabellen mit Milliarden von Zeilen bis hin zu sehr breiten, denormalisierten Tabellen. So lässt sich die Schreib-Performance über verschiedene Tabellenformen und Query-Komplexitäten hinweg vergleichen.

DML-Workloads: Hier löschen wir 1 Monat Daten aus der Tabelle und fügen ihn anschließend wieder ein. 1 Monat entspricht rund 1 % der Daten bzw. 6 Mio. Zeilen. Das testet sowohl die Effizienz des Query-Prunings (gezieltes Ansteuern dieses einen Monats) als auch die DML-Effizienz.

Warehouses

Für jeden Lauf und jedes Szenario wird zu Beginn automatisch ein neues Warehouse erzeugt und unmittelbar nach Abschluss wieder verworfen. So lassen sich die Gesamtkosten eines Warehouses isoliert betrachten, ohne dass Leerlaufzeiten das Bild verzerren.

Ein Databricks Serverless SQL Warehouse entspricht in etwa einem Snowflake Warehouse, das eine Größe darüber liegt. Beispiel: Ein Small in Databricks entspricht grob einem Medium in Snowflake. Wir haben die 4 oben genannten Szenarien auf folgenden Warehouse-Kombinationen ausgeführt.

• Snowflake Medium vs. Databricks Small
• Snowflake Large vs. Databricks Medium
• Snowflake XL vs. Databricks Large

Bestätigt wird dieser Größenvergleich durch die Dokumentationen von Snowflake und Databricks, wobei der Databricks Worker Count gleich den Snowflake Credits angesetzt wird.

Kostenzuordnung

Wir wollten die Kostenzuordnung so präzise wie möglich gestalten. Dafür kommen die oben beschriebenen isolierten Warehouses zum Einsatz. Wir nutzen die tatsächlichen Abrechnungsdaten (in Credits oder DBUs) für die Lebensdauer des jeweiligen Warehouses. Am Ende wenden wir mit einem flexiblen Kostenrechner unterschiedliche Preise pro Credit bzw. DBU auf die Ergebnisse an, um verschiedene Plattform-Tarife zu simulieren. So entfällt die gesamte Komplexität rund um die Kostenzuordnung bei parallelen Queries, Mindestabrechnungsintervallen usw. Wir betrachten einfach die Gesamtkosten pro Szenario.

Wenn wir die Kosten für einzelne Queries statt für ganze Läufe ausweisen, ordnen wir sie anteilig nach Laufzeit zu. Im Grunde verteilen wir die Gesamtkosten eines Laufs (bzw. der Lebensdauer des Warehouses) auf die Queries, sodass die Summe wieder stimmt.

Kostenvergleich

Der Databricks Standard Tier wird abgekündigt (bzw. wurde aller Voraussicht nach im Oktober 2025 abgekündigt). Vergleicht man also den niedrigsten Listenpreis beider Plattformen, ergibt sich Snowflake Standard zu 2 $ / Credit vs. Databricks Enterprise zu 0,70 $ / DBU. Das halten wir für einen fairen Vergleich, denn der Snowflake Standard Tier ist eine vollwertige Snowflake-Version – das wichtigste fehlende Feature ist Time Travel. Uns ist aber klar, dass viele Leserinnen und Leser Enterprise vs. Enterprise vergleichen möchten. Daher zeigen wir beides: Databricks zu 0,70 $ / DBU vs. Snowflake zu 2 $ / Credit und zu 3 $ / Credit.

Lauf-Historie und Analyse

Query-IDs und Lauf-Statistiken werden unmittelbar in eine lokale duckdb geloggt. Die Daten werden auf Ebene der Query-ID gespeichert (zuzüglich Run-ID, Warehouse, Szenario). Reporting-Views aggregieren die Daten, sodass wir Schlüsse über komplette Läufe ziehen können.

Queries

Die Benchmark-Queries finden Sie hier. (Auch wenn das SQL so aussieht, als sei es fest auf Scale Factor 100 verdrahtet, wird der Tabellenname zur Laufzeit dynamisch durch den Scale Factor aus Ihrer Konfigurationsdatei ersetzt. Alle Tests liefen auf Scale Factor 1000.) Wir haben die 22 Queries nach Komplexität und Anzahl der Joins in Kategorien gegliedert. Die detaillierte Aufteilung finden Sie hier, dieser Screenshot liefert aber eine kompakte Übersicht.

Ziel und Setup

Ziel: Queries sequenziell auszuführen bildet das nach, was Sie am Schreibtisch erleben, wenn Sie Queries gegen diese Datenplattformen absetzen. Genau so erleben Endanwender ein SELECT-Statement. Diese Messung erlaubt uns, Query für Query und Warehouse für Warehouse zu vergleichen – ähnlich wie bei den meisten TPC-H-Benchmarks.

Setup: Das Setup ist denkbar einfach: Wir führen 22 Queries nacheinander aus. In allen Szenarien wird das Warehouse zu Beginn des Laufs erzeugt und direkt nach der letzten Query wieder verworfen. Die Ergebnisse werden unmittelbar in die duckdb geloggt.

In diesem Szenario ist nur Query 1 ein echter "Cold Start"; die Queries 2 bis 22 gelten als warm, da das Warehouse während des gesamten Laufs aktiv bleibt.

Ergebnisse

Snowflake zu 2 $ / Credit vs. Databricks zu 0,70 $ / DBU:

Snowflake zu 3 $ / Credit vs. Databricks zu 0,70 $ / DBU:

Bei 2 $ / Credit ist Snowflake 34 % schneller und 17 % günstiger. Bei 3 $ / Credit dreht sich das Bild: Databricks wird 20 % günstiger.

Ziel und Setup

Ziel: Damit simulieren wir das Laden eines BI-Dashboards oder Jobs, bei denen Dutzende Queries gleichzeitig abgefeuert werden. Im Fokus steht, wie die Plattformen mit Concurrency umgehen.

Setup: Mit Python haben wir alle 22 Queries gleichzeitig gestartet und die Ergebnisse erfasst.

Ergebnisse

Snowflake zu 2 $ / Credit vs. Databricks zu 0,70 $ / DBU:

Snowflake zu 3 $ / Credit vs. Databricks zu 0,70 $ / DBU:

In beiden Szenarien war Snowflake schneller und günstiger! Für parallele Workloads scheint Snowflake hier (in diesem Benchmark-Szenario) also vorn zu liegen.

Schauen wir uns aber an, wie gut jede Plattform die Parallelität tatsächlich bewältigt. Bei perfekter Concurrency (kein Queuing, keine Ressourcenkonkurrenz) sollte die Gesamtlaufzeit des Parallel-Tests etwa der längsten isoliert ausgeführten Query entsprechen.

Plattform	Warehouse-Größe	Längste isolierte Query	Parallel-Wallclock	Verhältnis
Databricks	SMALL	134,5 Sek.	369,5 Sek.	2,7x
Databricks	MEDIUM	64,5 Sek.	296,0 Sek.	4,6x
Databricks	LARGE	32,9 Sek.	176,5 Sek.	5,4x
Snowflake	MEDIUM	94,7 Sek.	278,7 Sek.	2,9x
Snowflake	LARGE	45,2 Sek.	142,8 Sek.	3,2x
Snowflake	XLARGE	20,7 Sek.	99,7 Sek.	4,8x

Die Daten zeigen: Beide Plattformen zahlen einen Preis für parallele Queries (mehrere Queries gleichzeitig machen alle langsamer oder es entsteht Queuing) – aber Snowflake hat in diesem Vergleich das bessere Verhältnis.

Bei 22 parallelen Queries hat Snowflake bei Medium und Large auf 4 Cluster hochskaliert und bei XL nur 3 Cluster genutzt. Deshalb kostet XL auch nur wenige Cent mehr als Large.

Bei Databricks sind die gleichen Daten leider nicht verfügbar. Ich habe keinen Weg gefunden, herauszufinden, wie viele Cluster zum Einsatz kamen.

Ziel und Setup

Ziele: Laufzeiten ohne "Warehouse-Cache" messen und prüfen, ob die Warehouse-Startzeit das Ergebnis beeinflusst.

Beide Plattformen nutzen einen "Warehouse-Cache" bzw. "Photon Acceleration" – einen Cache auf der VM, die die Query ausführt. Bei sequenziellen Ausführungen profitiert Query 2 von Teilen des Caches, den Query 1 erzeugt hat usw.

Setup: Um zu sehen, wie Queries ohne Cache abschneiden, haben wir ein Szenario entworfen, das das Warehouse zwischen den Query-Ausführungen herunterfährt. In diesem Fall haben wir bewusst nicht alle 22 Queries laufen lassen – das hätte zu viel Geld gekostet.

Die Erstellungszeit des Warehouses zählt nicht zur Gesamt-Wallclock-Zeit, die Startzeit des Warehouses dagegen schon.

Die Queries

Query	Kategorie	Komplexität	Beschreibung
Q1	Einfache Aggregation & Filterung	Niedrig (Warm-up)	Mehrere Aggregationen (SUM, AVG, COUNT) mit GROUP BY auf einer Tabelle mit 600 Mio. Zeilen
Q3	Einfache Joins (2–4 Tabellen)	Mittel (Standard-OLAP)	3-Wege-Join mit Aggregation und Datumsfilter
Q5	Komplexe Joins (5+ Tabellen)	Hoch (Stresstest)	6-Wege-Join mit Umsatzberechnung und geografischem Filter
Q10	Einfache Joins (2–4 Tabellen)	Mittel (Standard-OLAP)	4-Wege-Join mit selektivem Filter und GROUP BY mit hoher Kardinalität
Q18	Subqueries & Semi-Joins	Mittel (Standard-OLAP)	IN-Subquery mit Aggregationsfilter (HAVING)

Query Kategorie Komplexität Beschreibung Q1 Einfache Aggregation & Filterung Niedrig (Warm-up) Mehrere Aggregationen (SUM, AVG, COUNT) mit GROUP BY auf einer Tabelle mit 600 Mio. Zeilen Q3 Einfache Joins (2–4 Tabellen) Mittel (Standard-OLAP) 3-Wege-Join mit Aggregation und Datumsfilter Q5 Komplexe Joins (5+ Tabellen) Hoch (Stresstest) 6-Wege-Join mit Umsatzberechnung und geografischem Filter Q10 Einfache Joins (2–4 Tabellen) Mittel (Standard-OLAP) 4-Wege-Join mit selektivem Filter und GROUP BY mit hoher Kardinalität Q18 Subqueries & Semi-Joins Mittel (Standard-OLAP) IN-Subquery mit Aggregationsfilter (HAVING)

Ergebnisse

Hier zeigt sich: Snowflake war um Größenordnungen schneller und sogar etwas günstiger.

Im Detail lag die Startzeit von Databricks bei rund 7 Sekunden pro Start, während Snowflake in allen Fällen unter einer Sekunde startete.

Ziel und Setup

Ziel: Schreibintensive Operationen messen, wie sie in Data-Engineering-Aufgaben und dbt-Projekten typisch sind. Die Standard-TPC-H-Queries sind auf analytische Reads optimiert: Sie scannen große Datensätze, liefern aber kleine, aggregierte Ergebnisse (Summen, Durchschnitte, Top-N-Listen). Das testet zwar Query-Ausführung und -Optimierung – aber eben nicht die Schreib-Performance. Wir wollten wissen, wie Snowflake und Databricks beim Schreiben von Milliarden von Zeilen mit unterschiedlichen Datenformen abschneiden.

Setup: Wir haben 5 CTAS-Varianten erstellt, die jeweils ein bestimmtes Schreibmuster testen:

1. Schmal & hoch (6 Mrd. Zeilen × 4 Spalten): Eine einfache Projektion der LINEITEM-Tabelle mit nur 4 Schlüsselspalten (l_orderkey, l_partkey, l_quantity, l_extendedprice). Das testet den maximalen Zeilen-Durchsatz bei minimalem Spalten-Overhead.
2. Standard hoch (6 Mrd. Zeilen × 16 Spalten): Eine vollständige Kopie der LINEITEM-Tabelle (SELECT * FROM LINEITEM). Steht für das gängige Muster, große Fakten-Tabellen zu duplizieren oder zu archivieren. (Normalerweise würde man dafür Clone einsetzen, aber Clone-Operationen sind heute nicht Teil des Benchmarks.)
3. Mittel-breit (1,5 Mrd. Zeilen × 30 Spalten): Ein Join der Tabellen ORDERS, CUSTOMER, NATION und REGION. Das testet die Kombination aus Read- und Write-Performance bei moderater JOIN-Komplexität und einem breiteren Schema – typisch für die Denormalisierung von Star-Schemas.
4. Sehr breit (6 Mrd. Zeilen × 59 Spalten): Ein vollständig denormalisierter Join über alle TPC-H-Tabellen (LINEITEM, ORDERS, CUSTOMER, SUPPLIER, PART, PARTSUPP, NATION, REGION). Der Extremfall breiter, vor-joinierter Tabellen, wie sie in Analytics-Layern üblich sind.
5. Gefiltert (2 Mrd. Zeilen × 16 Spalten): LINEITEM gefiltert auf Bestellungen, die nach 1995 versendet wurden (WHERE l_shipdate >= '1995-01-01'). Das testet den Schreib-Durchsatz bei Teilkopien einer Tabelle – ein gängiges Muster in inkrementellen Datenpipelines.

Ergebnisse

Snowflake zu 2 $ / Credit vs. Databricks zu 0,70 $ / DBU:

Snowflake zu 3 $ / Credit vs. Databricks zu 0,70 $ / DBU:

Snowflake zu 2 $ / Credit vs. Databricks zu 0,70 $ / DBU, ohne die Ausreißer-Query "Sehr breit":

Snowflake zu 3 $ / Credit vs. Databricks zu 0,70 $ / DBU, ohne die Ausreißer-Query "Sehr breit":

Man kann mit gutem Gewissen sagen: In diesem Benchmark-Szenario hat Databricks beim Erstellen großer Tabellen via CTAS klar die Nase vorn.

Ziel und Setup

Ziel: Delete + Insert ist ein gängiges Muster, um Daten inkrementell zu aktualisieren. Es ist die effektivste Methode, gezielt Datensegmente in großen Tabellen zu transformieren – und damit ein wichtiges Test-Szenario.

Setup: Zu Beginn des Laufs wird eine Kopie der Quell-Benchmark-Daten erstellt. Diese fließt weder in die Laufzeit noch in die Kostenmetriken ein. Sobald die Kopie steht, beginnt der Benchmark-Prozess. Es wird 1 Monat Daten gelöscht – rund 6 Mio. Zeilen bzw. etwa 1 % der Gesamtdaten. Anschließend wird derselbe Monat aus der Quelle wieder eingefügt. Das bildet ein reales ETL-Szenario ab, in dem übereinstimmende Datensätze gelöscht und neu eingefügt werden. Hinweis: Wir haben bewusst kein merge verwendet, da bekannt ist, dass Delete + Insert performanter ist als merge.

Ergebnisse

Snowflake zu 2 $ / Credit vs. Databricks zu 0,70 $ / DBU:

Snowflake zu 3 $ / Credit vs. Databricks zu 0,70 $ / DBU:

Die Ergebnisse hier sind wirklich spannend. Snowflake M, L und XL verarbeiten die Daten alle in unter 20 Sekunden – Grund ist das exzellente Query-Pruning. Die 6 Milliarden Zeilen werden so weit beschnitten, dass effektiv nur 6 Millionen Zeilen verarbeitet werden. Das Small-Warehouse braucht mehr als doppelt so lange, weil es sowohl beim Delete- als auch beim Insert-Schritt zu Spillage kommt.

Bei Databricks passiert dasselbe. Wir sehen eine Konzentration zwischen 35 und 39 Sekunden über alle Warehouse-Größen hinweg. Auch Databricks reduziert die Datensatzgröße effektiv, sodass M, L und XL problemlos zurechtkommen. Nur eben nicht ganz so schnell wie Snowflake.

Wenn Sie die Tests selbst durchführen möchten, ist das relativ einfach. Wie oben erwähnt: Der erste Schritt ist, den 1000x-Datensatz per ETL von Snowflake nach Databricks zu bringen. Das ist der schwierige Teil – und der einzige, für den wir keine Automatisierung mitliefern, da hier zu viele Variablen im Spiel sind. Auch hier empfehle ich Estuary!

Sobald die Daten in Ihrem Databricks-Account verfügbar sind, können Sie der Getting-Started-Anleitung hier folgen. Sie brauchen lediglich UV und die Snowflake CLI installiert, richten Ihre .env-Datei per uv run setup_config.py ein – und schon können die Benchmarks losgehen! Die Readme enthält viele Beispiele, wie Sie einzelne Szenarien, Warehouse-Größen oder den kompletten Lauf in einem Rutsch starten.

Nach dem Benchmark-Lauf müssen Sie 2 Stunden warten, bis sich die Abrechnungsdaten stabilisiert haben. Anschließend führen Sie uv run enrich.py aus, um die Ergebnisse mit den Abrechnungsdaten anzureichern. Wenn Sie die Ergebnisse visualisieren möchten, folgen Sie auch dafür den Schritten in der Readme.

Die Ergebnisse zeigen eindeutig: Snowflake Standard Edition ist in allen Szenarien die kosteneffizienteste Plattform – mit Ausnahme des CTAS-Szenarios, in dem Databricks Snowflake sowohl bei Kosten als auch bei Performance schlägt. Mit einem Upgrade auf Snowflake Enterprise Edition zu 3 $ / Credit wird Databricks in einigen Szenarien günstiger. Und nochmal: Benchmarks bleiben Benchmarks – testen Sie unbedingt mit Ihren eigenen Daten!

Jeff ist Data- und Analytics-Berater mit über 15 Jahren Erfahrung darin, Insights zu automatisieren und Geschäftsprozesse mit Daten zu steuern. Technologisch ist er auf Snowflake + dbt + Tableau spezialisiert. Inhaltlich bringt er Erfahrung aus den Bereichen öffentliche Versorgungswirtschaft, klinische Studien, Verlagswesen, Konsumgüter und Fertigung mit. Melden Sie sich jederzeit gern: [email protected].