Snowflake Generation 2 (Gen2) Warehouses: Rechtfertigt das Tempo die Mehrkosten?

Gen2 Warehouses nutzen schnellere Hardware der zugrunde liegenden Cloud-Anbieter (AWS, GCP). Zusätzlich hat das Snowflake-Team gezielt in Software-Optimierungen für Gen2 investiert, die zusätzliche Performance- und Kostenvorteile bringen. Nahezu alle Queries profitieren bereits von den Hardware-Verbesserungen, bestimmte Workloads holen über die Software-Optimierungen noch mehr heraus.

Gen2 Warehouses sind aktuell nur eingeschränkt verfügbar, dürften aber zeitnah in weiteren Regionen ausgerollt werden. Ob Gen2 in Ihrer Region verfügbar ist, sehen Sie hier.

Hardware-Verbesserungen

Gen2 Virtual Warehouses laufen auf der Compute-Infrastruktur Ihres Cloud-Anbieters, also etwa auf EC2-Instanzen oder virtuellen Maschinen. Die Anbieter modernisieren ihre Instanzen laufend mit neuerer Hardware – AWS hat zum Beispiel kürzlich die ARM-basierten Graviton4-Prozessoren eingeführt. Snowflake nennt die konkret eingesetzte Hardware zwar nicht, es liegt aber nahe, dass jeweils die aktuellen Generationen der Anbieter zum Einsatz kommen. Zu diesen Hardware-Verbesserungen gehören schnellere lokale Festplattenzugriffe, mehr CPU-Leistung und höherer Netzwerkdurchsatz – allesamt Faktoren, die sich unmittelbar in besserer Out-of-the-Box-Query-Performance niederschlagen.

Software-Verbesserungen

Snowflake hat zudem eine Reihe gezielter Software-Optimierungen vorgenommen, die DML-Workloads (also Jobs, die Daten in Tabellen mergen oder aktualisieren) sowie bestimmte komplexe Queries beschleunigen.

Wie unsere Analyse zeigen wird, dürften diese Software-Verbesserungen hinter einigen der größten Performance-Sprünge stecken.

Da Gen2 Warehouses auf neuerer, leistungsfähigerer Hardware laufen, sind sie auch teurer. Wie die Preisübersicht unten zeigt (Quelle), kosten Gen2 Warehouses in AWS und GCP 35 % mehr, in Azure 25 % mehr.

Das hat spürbare Folgen, die Sie vor dem Umstieg in jedem Fall durchrechnen sollten. Selbst wenn Queries schneller laufen, muss die kürzere Compute-Zeit die höheren Kosten auch wirklich ausgleichen. Hinzu kommt: Die meisten Teams konfigurieren ihre Warehouses so, dass sie nach 60 Sekunden Leerlauf suspendiert werden. In dieser Idle-Zeit zahlen Sie den höheren Preis – ein Punkt, den Sie in Ihre Analyse einbeziehen sollten.

Break-Even-Berechnung

Da Queries auf Gen2 schneller laufen und Sie den höheren Tarif kürzer zahlen, lautet die Break-Even-Formel:

Erforderliche Zeitersparnis (%) = 1 - (1 / Preissteigerungsfaktor)

In Azure müssen Sie die Warehouse-Laufzeit um 20 % reduzieren, um Break-Even zu erreichen.

• 1 - (1 / 1.25) = 0,20

In AWS sind es 25,9 %.

• 1 - (1 / 1.35) = 0,259

Meine Benchmarks habe ich in AWS durchgeführt. Um kostenneutral zu bleiben, muss die Performance also um mindestens 25,9 % steigen.

Die 1-Minuten-Mindestabrechnung nicht vergessen

Wichtig: Jedes Mal, wenn ein Warehouse startet, werden Ihnen 60 Sekunden in Rechnung gestellt. Läuft eine Query auf Gen1 also 30 Sekunden und auf Gen2 nur 15 Sekunden, sparen Sie nichts – Sie zahlen mehr. Ob die Performance-Gewinne die Mehrkosten rechtfertigen, müssen Sie selbst entscheiden.

Das ideale Einsparszenario: Workloads, die länger als eine Minute laufen UND mehr als den oben genannten Break-Even-Prozentsatz einsparen.

Die Tabelle unten fasst das Konzept zusammen.

Ein neues Gen2 Warehouse anzulegen oder ein bestehendes umzustellen, ist denkbar einfach: Geben Sie dem create- oder alter-Statement einfach den Parameter resource_constraint mit. Hier ein Beispiel für beide Varianten:

-- create new
CREATE OR REPLACE WAREHOUSE my_wh
WAREHOUSE_SIZE = MEDIUM
RESOURCE_CONSTRAINT = STANDARD_GEN_2;

-- alter existing
ALTER WAREHOUSE legacy_wh
SET RESOURCE_CONSTRAINT = STANDARD_GEN_2;

Snowflake bringt eine Sample-Datenbank mit dem TCP-H-Datensatz mit. TCP-H ist ein vom Transaction Processing Performance Council definierter Datensatz für das Benchmarking analytischer Workloads.

In Snowflake finden Sie diese Schemas in der Datenbank snowflake_sample_data:

• TPCH_SF1
• TPCH_SF10
• TPCH_SF100
• TPCH_SF1000

SF steht für Scale Factor. SF10 ist 10-mal größer als SF1 und so weiter. Wir haben verschiedene Workload-Typen jeweils auf SF10, SF100 und SF1000 getestet.

Unser Benchmarking deckt drei Hauptszenarien ab:

1. dbt: Aufbau eines dbt-Projekts, das ausschließlich aus Table-Models und Tests besteht. Damit prüfen wir, ob dbt-Projekte – auf Snowflake weit verbreitet – gute Kandidaten für Gen2 Warehouses sind.
2. Select-Queries: Hier simulieren wir, was in einem BI-Tool oder anderen nutzerseitigen Anwendungen passiert.
3. DML-Workloads: Das Aktualisieren bzw. Mergen neuer Daten in Snowflake ist Alltag für Data-Engineering-Teams. Wir haben verschiedene DML-Szenarien (Updates, Merges usw.) getestet, um deren Verhalten zu verstehen.

dbt

Setup

Wir haben ein bestehendes dbt-Projekt geforkt und aktualisiert, das mit den Snowflake-TCPH-Datensätzen arbeitet. Unser Repo finden Sie hier.

Wir haben das dbt-Projekt ohne Einschränkungen gegen jeden Datensatz laufen lassen, mit Warehouses unterschiedlicher Größe, und Gen1 mit Gen2 verglichen. Für kleinere Daten kamen kleinere Warehouses zum Einsatz, für größere Daten entsprechend größere – um ein realistisches Szenario abzubilden.

Jede Iteration wurde in einem frischen Schema gebaut, um Caching zu vermeiden und die Ergebnisse jedes Tests separat festzuhalten. Jeder Build führt 16 Table-Models und 43 Data-Tests aus (dbt build --exclude tag:merge-test).

Ergebnisse

Hier die Ergebnisse:

Die Arbeit in diesem dbt-Projekt besteht zu rund 97 % aus CTAS-Queries (Table-Models) und zu 3 % aus dbt-Tests (einfache Select-Queries).

Daraus folgt: Für dbt-Table-Models in diesem konkreten Projekt ist der Performance-Gewinn nicht immer hoch genug, um die zusätzlichen 35 % Kosten zu rechtfertigen.

Erwähnenswert: Das 4XL-Gen2-Warehouse hatte mit über 5 Minuten eine sehr lange Cold-Start-Zeit, während das Gen1-4XL sofort verfügbar war. Da die Resume-Zeit nicht berechnet wird, haben wir sie aus dem Ergebnis herausgerechnet, indem wir das Warehouse vor dem dbt-Lauf vorgestartet haben. Provisionierungszeiten sind bei ETL-Jobs, die nachts laufen, in der Regel kein Thema – erwähnenswert ist es trotzdem.

Einfache Select-Statements

Wir haben eine Auswahl an Select-Queries aus den TPCH-Datensätzen ausgeführt, um den Einsatz in einem BI-Tool oder anderen nutzerseitigen Anwendungen zu simulieren. Die konkret ausgeführten Queries sind in der Tabelle verlinkt. Hier die Ergebnisse:

Die Query "Select, Aggreage" finden Sie hier.

Die Query "Select, join, aggregate" finden Sie hier.

Diese Select-Statements zeigen deutliche Performance-Gewinne und sparen auf Gen2 allesamt Geld – pro Sekunde betrachtet. Aber: Da nutzerseitige Queries schnell sein müssen, schlägt hier die Snowflake-Eigenart der Mindestabrechnung zu. Laufen Queries weniger als 60 Sekunden und/oder steht das Warehouse längere Zeit im Leerlauf (was in BI-Tools üblich ist), bleibt Gen1 die Empfehlung – es sei denn, Sie optimieren bewusst auf Geschwindigkeit und können die Mehrkosten verkraften.

Außerdem öffnen Gen2 Warehouses die Tür dafür, die Warehouse-Größe zu reduzieren. Beispiel: Halbieren sich die Query-Zeiten mit Gen2, steigen aber die Kosten durch teurere Idle-Zeit, können Sie die Warehouse-Größe halbieren, dieselbe Query-Performance zu niedrigeren Kosten erreichen und so spürbare Einsparungen erzielen.

DML: Updates auf großen Tabellen

Die Updates in diesem Abschnitt sind allesamt einfache Updates nach dem Muster update table <tbl> set column <col> = value. Beachten Sie: Auch wenn nur eine einzige Spalte aktualisiert wird, muss Snowflake die gesamte Micro-Partition für die betroffene Zeile neu schreiben. Effektiv erfordern diese beiden Befehle also denselben "Arbeitsaufwand" von Snowflake:

update orders_table set customer_id=5 where order_id=1;
update orders_table set customer_id=5, amount=22.05, order_date='2025-05-01',
<many columns>
where order_id=1;

Wir haben hier drei Szenarien getestet:

• Ein Update ohne where-Klausel auf 6 Milliarden Zeilen.
• Ein selektives Update auf derselben Tabelle, bei dem nur 2,4 Millionen Zeilen (0,04 % der Tabelle) aktualisiert werden.
• Ein Update einer einzelnen Zeile.
• Die SQL-Statements finden Sie hier.

Das Ergebnis ist meines Erachtens recht eindeutig: Gen2 Warehouses sind bei gefilterten Updates ausgesprochen stark – vermutlich dank der gezielten Software-Optimierungen, die Snowflake veröffentlicht hat.

Sehen wir uns die Query mit -79 % Kostendifferenz genauer an, um zu verstehen, woher diese enorme Verbesserung kommt.

Der Screenshot zeigt eine Reduktion der geschriebenen Bytes um 99 %!

(0,16 GB – 16,56 GB) / 16,56 GB = -99 %

DML: Merge-Queries

Setup

Anders als die einfachen Updates oben aktualisieren Merge-Queries Datensätze in der Zielmenge auf Basis von Datensätzen einer Quelle. Dabei wird ein Join verwendet, um übereinstimmende Datensätze zu aktualisieren und neue einzufügen.

Die Merge-Queries mit n % aktualisierten Zeilen sind inkrementelle dbt-Models. Sie werden über dbt run -s pre_merge+ ausgeführt, wobei der Row-Limit-Filter in Zeile 22 angepasst wird. Sie simulieren einen realistischen Incremental-Fall, in dem nur ein Bruchteil der Daten neu oder geändert ist. Um den Prozentsatz der aktualisierten Daten zu ändern, passen wir diese Zeile an und führen das Model plus das nachgelagerte inkrementelle Model aus.

Die Tasks "Merge, all rows updated" stammen aus dieser Query, die jede Zeile in den Daten aktualisiert.

Zur Einordnung: Der SF10-Datensatz umfasst rund 60 Millionen Zeilen, SF100 etwa 600 Millionen Zeilen.

Ergebnisse

Die obigen Ergebnisse zeigen eindeutig, dass Merge-Queries, die nur wenige Datensätze aktualisieren, einen größeren Performance-Gewinn erzielen als vollständige Merges.

Den Beleg liefert das Query-Profil, das mehrere bemerkenswerte Details offenbart. Zunächst sank die Netzwerkkommunikation deutlich von 41 % auf 13 %. Diese Veränderung dürfte auf den drastischen Rückgang der geschriebenen Bytes zurückzuführen sein – von 1,6 GB auf nur noch 4,65 MB. Das legt nahe, dass Snowflake die Kompression verbessert oder die Datenübertragung über das Netzwerk optimiert hat. Da beide Queries nur 100 Zeilen aktualisieren, stützt das die Annahme, dass Gen2 spezifische Optimierungen für effizienteres Schreiben enthält.

Eine Anomalie

Die eine Anomalie (in der vorletzten Zeile mit nur 1 % Ersparnis) ist wirklich interessant, denn Snowflake zeigt hier, dass 99,5 % weniger Bytes geschrieben wurden. Mögliche Erklärungen sind unter anderem S3-Throttling und Netzwerkgeschwindigkeit.

Alle obigen Ergebnisse beziehen sich auf eine Pro-Sekunde-Betrachtung. Wie eingangs erwähnt, ist die Idle-Zeit nach Beendigung der Queries jedoch ein eigener Faktor. Skizzieren wir ein einfaches Szenario. In der Tabelle unten gehen wir davon aus, dass Gen2 eine Query in 50 % weniger Zeit ausführt als Gen1 – eine sehr großzügige Annahme, aber halten wir es einfach. Außerdem nehmen wir ein Auto-Suspend von 60 Sekunden an. Das ergibt:

Klar ist: Je länger der Workload läuft, desto geringer ist dieser Effekt. Die Tabelle unten verdeutlicht, wie der Einfluss mit zunehmender Query-Dauer abnimmt:

Dieses Phänomen lässt sich als Funktion ausdrücken:

% Idle-Zeit = [Auto-Suspend-Sekunden] / ([Query-Zeit] + [Auto-Suspend-Sekunden])

Für Snowflake-Kunden, die auf Performance optimieren wollen, ist der Einfluss der Idle-Zeit vernachlässigbar – verglichen mit den Kosten, die das manuelle Feintuning durch einen Data Engineer und die dabei verbrauchten Credits verursachen! Berücksichtigen sollte man die Idle-Zeit dennoch.

Aggregierte Ergebnisse im Blick

Aggregierte Ergebnisse können trügerisch sein, denn sie hängen stark davon ab, wie viele Queries wir in jeder Kategorie und Warehouse-Größe ausgeführt haben. Sie verdecken außerdem, dass einzelne Queries innerhalb einer Kategorie deutlich anders abschneiden können als der Durchschnitt.

Trotzdem lohnt sich der Blick auf die aggregierten Daten – sie zeigen, wie stark Kosten und Performance variieren.

Unten finden Sie die Ergebnisse der obigen Tests, übersichtlich konsolidiert.

Die Lehre daraus: Probieren Sie es immer mit Ihrem eigenen Datensatz aus, um zu sehen, wie Gen2 in Ihren konkreten Use Cases abschneidet. Wie bei den meisten Themen in der Cloud lässt sich kaum pauschal sagen, welches Tooling universell günstiger oder besser ist – es kommt immer auf den Use Case an.

Dennoch lassen sich einige zentrale Erkenntnisse festhalten:

• Wir haben jetzt einen aufwandsfreien Hebel, um Queries zu beschleunigen und meist auch die Kosten zu senken.
• Einfache Select-Queries gehörten in unseren Tests zu den Top-Performern und sparten 26 % der Kosten.
  • Allerdings können sie teurer werden, wenn sie auf nicht ausgelasteten Warehouses unterhalb der Mindestabrechnungsdauer laufen.
  • Bedenken Sie: Es kann durchaus sinnvoll sein, 10 % mehr zu zahlen (etwa 10.000 USD/Jahr) für eine aufwandsfreie 20%ige Verbesserung für alle Business-User. Stellen Sie die Mehrkosten dem Aufwand gegenüber, den Sie selbst für entsprechende Performance-Optimierungen aufbringen müssten.
• Gen2 ist Gen1 bei gezielten Updates und einfachen Select-Queries mit Full Table Scans haushoch überlegen.
• Gen2 ist nicht zwangsläufig günstiger für durchschnittliche dbt-Table-Models. Das liegt vermutlich am Neuschreiben aller Datenpartitionen über "create or replace table as". Bei inkrementellen Models mit Merge-Statements kann es jedoch günstiger und schneller sein.

Ein hervorragender Use Case für Gen2 Warehouses ist meiner Meinung nach folgender: Ihr aktuelles Warehouse stößt an seine Grenzen und Sie überlegen, etwa von Medium auf Large hochzuskalieren. Statt auf Large zu wechseln – wo die Credits 100 % mehr kosten – probieren Sie es mit einem Gen2 Medium und zahlen nur 35 % mehr pro Credit. Persönlich sehe ich Gen2 mittlerweile als halbe Stufe zwischen den Warehouse-Größen.

• Die Gesamtersparnis lag bei 2 % – wird allerdings stark durch die beiden größten Workloads verzerrt.
• Lässt man die beiden größten Credit-Verbraucher außen vor, beträgt die Gesamtersparnis 7 %.

Als wir unsere Benchmark-Ergebnisse mit jemandem von Snowflake besprachen, sagte er einen Satz, der bei uns hängengeblieben ist: "Das Einzige, was ein Benchmark Ihnen sagt, ist, wie schnell der Benchmark gelaufen ist." Es gibt viele Faktoren, die beeinflussen, wie sich das auf Ihre Produktions-Workloads auswirkt.

• Fehlende Parallelität: Benchmarks laufen meist auf nicht ausgelasteten Warehouses, auf denen Parallelität kein Thema ist.
• Transientes Rauschen: Dieselbe Query unter denselben Bedingungen kann zu einem anderen Zeitpunkt um rund 10 % nach oben oder unten schwanken – bedingt durch natürliche Schwankungen der Cloud-Infrastruktur (transiente Probleme, AWS-S3-Service-Throttling usw.).

Wir empfehlen, Gen2 für einen gewissen Zeitraum – etwa eine Woche – auf ausgewählten Workloads zu betreiben, um die tatsächliche Kostenwirkung in Ihrer Umgebung zu beurteilen.

Bei SELECT wollen wir einen robusteren, wissenschaftlicheren Ansatz für das Benchmarking aufbauen. Wir stellen uns ein Szenario vor, in dem Python dieselbe Query mehrfach gegen denselben Datensatz mit unterschiedlichen Warehouses ausführt. So erhalten wir eine größere Stichprobe, in der einzelne Ergebnisse den Mittelwert weniger stark beeinflussen. Bleiben Sie dran!

Wir freuen uns auf Ihre Erfahrungen mit Gen2 Warehouses! Melden Sie sich gern und teilen Sie spannende Erkenntnisse oder Kosteneinsparungs-Stories mit uns!

Jeff ist Data- und Analytics-Consultant mit über 15 Jahren Erfahrung in der Automatisierung von Insights und der datengetriebenen Steuerung von Geschäftsprozessen. Technologisch ist er auf Snowflake + dbt + Tableau spezialisiert. Inhaltlich bringt er Erfahrung aus Energieversorgung, klinischen Studien, Verlagswesen, CPG und Fertigung mit. Kontakt jederzeit gerne unter [email protected].

Ian Whitestone · Co-Founder & CEO von SELECT

Ian ist Co-Founder und CEO von SELECT, einer SaaS-Plattform für Snowflake-Kostenmanagement und -Optimierung. Vor SELECT leitete er sechs Jahre lang Full-Stack-Data-Science- und Engineering-Teams bei Shopify und Capital One. Bei Shopify verantwortete er die Optimierung des Data Warehouse und den Ausbau der Kostentransparenz.