Snowflake-Kostenmanagement 2026: Das Wichtigste aus unserem Webinar

• Die Snowflake-Plattform geht längst weit über Compute und Storage hinaus – und jeder neue Service ist eine neue Stelle, an der sich Kosten verstecken können.
• Snowflakes Cortex-AI-Funktionen sind leistungsstark, aber auch der einfachste Weg, versehentlich Tausende Dollar zu verbrennen. Ein Kunde gab in drei Tagen 60.000 $ für eine Query aus, die eigentlich in der QA laufen sollte – und stattdessen in der Produktion lief.
• Erst Transparenz, dann Optimierung. Teams finden immer wieder Workloads, die Hunderttausende Dollar pro Jahr kosten und von deren Existenz niemand wusste.
• Die Maßnahmen mit dem höchsten ROI sind meist simpel: Jobs seltener laufen lassen und Warehouses per Right-Sizing anpassen – statt Queries umzuschreiben.
• Kostenmanagement in einer wachsenden Organisation zu skalieren heißt, Teams eigene Transparenz zu geben, statt jede Kostenfrage über ein zentrales Team zu leiten.

Snowflake stand früher für Compute und Storage. Dieses Bild greift heute zu kurz. Ian und Dave gingen die wachsende Liste an Services durch, die Kunden heute auf der Plattform betreiben: native Apps, Streamlit-Apps, Machine-Learning-Modelle auf Compute Pools, ein schnell wachsendes Set an AI-Funktionen und – seit der Übernahme von Crunchy Data durch Snowflake – sogar Postgres-Workloads.

Jeder dieser Services taucht als neue Position auf der Rechnung auf. Das schafft ein echtes Tracking-Problem: Wenn Ihr Monitoring einen neuen Service gar nicht kennt, sehen Sie schlicht nicht, was er kostet. SELECT beschäftigt ein Team von knapp 30 Engineers, deren einzige Aufgabe es ist, mit Snowflakes Releases Schritt zu halten – neue Kostenquellen werden so direkt beim Launch unterstützt und nicht erst Monate später.

Dave ergänzte, dass das nicht nur ein technisches Ärgernis ist. Führungskräfte entscheiden zunehmend darüber, wo Workloads laufen sollen – und das geht nicht ohne echte Kostentransparenz als Grundlage.

Snowflakes Cortex-Funktionen (inzwischen AI SQL genannt) ermöglichen es, AI direkt auf Daten anzuwenden, die in Snowflake liegen. Daves Beispiel: Produktbewertungen mit einer einzigen Query auf genau die Fälle herunterfiltern, in denen Kunden Frust geäußert haben. Vor ein paar Jahren bedeutete das, dass Menschen jeden Datensatz von Hand prüfen und taggen mussten.

Diese Bequemlichkeit birgt ein reales Risiko. Dave schilderte ein Kundenbeispiel: Eine Query mit eingebauter Cortex-Funktion sollte in der QA laufen. Stattdessen lief sie in der Produktion gegen den kompletten Datenbestand und verbrannte in drei Tagen 60.000 $ an Tokens – ohne irgendein verwertbares Ergebnis.

Ian erklärte, warum das so leicht passiert. AI-Nutzung wird nach Input- und Output-Tokens abgerechnet. Input-Tokens lassen sich vorab grob abschätzen, weil man die Größe dessen kennt, was man dem Modell gibt. Output-Tokens nicht – wie viel das Modell generiert, hängt von der Fragestellung selbst ab. Diese Asymmetrie macht AI-Kosten so schwer vorhersehbar, bevor man etwas ausführt.

Wie bekommt man Transparenz über AI-Ausgaben auf Snowflake?

Das Account-Usage-Schema von Snowflake enthält mehrere Views für AI. Die meisten funktionieren wie andere Account-Usage-Views und zeigen die stündliche Nutzung aufgeschlüsselt nach Modell. Die AI-SQL-Usage-View arbeitet auf Query-Ebene: Sie sehen das verwendete Modell und den Query-Text, aber nicht den Prompt selbst. Die granularste Option ist die Tabelle mit AI-Observability-Events. Sie wird über eine Table Function statt über eine normale View abgefragt und kann die Prompts hinter der Nutzung zeigen. Sie ist tendenziell langsamer abzufragen und, so Ians Verständnis, nicht persistent – was Langzeitanalysen erschwert.

Stoppen Snowflakes AI-Budgets und -Quotas ausufernde Ausgaben wirklich?

Größtenteils – mit einer wichtigen Lücke. Mit AI-Budgets legen Sie ein monatliches Credit-Limit für ein Konto oder eine getaggte Gruppe von Objekten fest; sie decken Cortex Agents, Cortex Search und AI-Funktionen ab und warnen Sie, wenn das Limit überschritten wird. Quotas pro Nutzer gehen weiter und blockieren die Nutzung tatsächlich – wobei die Durchsetzung ein paar Minuten braucht und eine Query nicht sofort stoppt.

Die Lücke: Eine einzelne große Anfrage kann das Limit trotzdem sprengen, bevor das System hinterherkommt. Ians Beispiel: eine Sentiment-Analyse-Funktion in einem Rutsch über eine riesige Tabelle mit Bewertungen laufen zu lassen. So fallen schnell 10.000 $ an, und erst die nächste Query wird blockiert. Quotas fangen trotzdem die wiederholten oder übers Wochenende durchlaufenden Fälle ab, und Ian nannte deren Einrichtung die eine Sache, die man aus der Session mitnehmen sollte. Sie ersetzen aber keine guten Praktiken wie das Testen in der QA mit begrenzten Datensätzen, bevor man die Produktion anfasst.

Wie misst man den ROI von AI-Ausgaben?

Eine Universalformel gibt es nicht. Beginnen Sie mit der Seite, die sich präzise messen lässt: den Kosten. Auf der Wertseite hängt es vom Anwendungsfall ab. Ersetzt AI etwas, das es schon gab – etwa ein Team, das Sentiment manuell klassifiziert hat –, vergleichen Sie die alten Kosten in Zeit und Compute mit den neuen. Ermöglicht sie etwas Neues, arbeiten Sie meist mit Näherungswerten: eingesparte Zeit, Ticket- oder Story-Velocity aus einem System wie Jira oder zurückgewonnener Umsatz. Wenn all das keine klare Antwort liefert, war Ians Vorschlag unverblümt: abschalten und schauen, wer sich beschwert.

Bevor irgendeine Optimierungsarbeit beginnt, müssen Sie wissen, was die Dinge tatsächlich kosten. Ian schilderte das Beispiel eines Kunden, der sich zum ersten Mal bei SELECT einloggte und ganz oben auf seiner Liste einen Workload fand, der 850.000 $ pro Jahr kostete – getrieben vor allem von einer AI-Funktion in einem Job, der sich als QA-Job herausstellte. Sie schalteten ihn ab. Keine tiefgehende Analyse nötig, denn allein die Transparenz brachte die Lösung ans Licht.

Daves Variante derselben Lektion: ein Kunde, der 10.000 $ pro Jahr ausgab, nur um eine E-Mail aus Snowflake heraus zu verschicken. Ein Blick auf die echten Kosten genügte, um diesen Workload an einen günstigeren Ort zu verlagern. Außerdem hört er ständig "Das hatte ich doch vor drei Monaten abgeschaltet", sobald Kunden zum ersten Mal die Kosten pro Query und pro Workload sehen.

Haben Sie erst einmal Transparenz, lautet die nächste Frage, ob sich eine Optimierung überhaupt lohnt. Einen Engineering-Tag zu investieren, um 500 $ bei Storage zu sparen, ist ein Verlustgeschäft. Ein paar Stunden für 20.000 $ Ersparnis sind ein klares Ja. Ians Rat: Rechnen Sie das durch, bevor Sie anfangen, und nehmen Sie die Quick Wins mit, bevor Sie auch nur eine Zeile SQL umschreiben.

Welche Maßnahmen bringen den höchsten ROI, wenn man weiß, wo man suchen muss?

1. Lassen Sie Jobs seltener laufen. Ein Job, der stündlich läuft und 10.000 $ pro Jahr kostet, fällt auf unter 500 $ pro Jahr, wenn er nur täglich laufen muss – eine Reduktion um 96 % durch eine einzige Konfigurationsänderung. Schon der Wechsel von stündlich auf alle drei Stunden spart rund zwei Drittel der Kosten.
2. Right-Sizing für Ihr Warehouse. Jede Größenstufe verdoppelt Compute und Kosten – ein größeres Warehouse lohnt sich also nur, wenn sich die Query-Zeit tatsächlich auch halbiert. Ians Beispiel: Ein Ingestion-Warehouse von Large auf Extra Small zu verkleinern, erhöhte die durchschnittliche Query-Zeit von etwa fünf auf etwa zwanzig Sekunden – eine Verzögerung, die niemandem auffiel – und sparte 50.000 $ pro Jahr. Eine nützliche Faustregel: rund 125 gescannte Partitionen pro CPU-Kern (ein Large Warehouse hat 64 Kerne). Eine Query, die nur 500 Partitionen scannt, braucht also selten mehr als ein Extra Small.
3. Achten Sie auf das Muster "Snowflake als Message Queue". Dave hat Teams gesehen, die Snowflake wie eine Kafka-Queue nutzen und Millionen winziger Operationen ausführen statt der größeren Batch-Operationen, für die die Plattform gebaut ist. Das hält Warehouses pausenlos am Laufen und wird teuer. Setzen Sie für jeden Workload die passende Technologie ein.
4. Denken Sie an horizontale Skalierung, nicht nur an vertikale. Dave wies darauf hin, dass viele eine Warehouse-Größe wählen und die Cluster-Anzahl vernachlässigen. Je nach Workload kann eine höhere Cluster-Anzahl bessere Ergebnisse liefern als eine schlichte Vergrößerung des Warehouse.
5. Nutzen Sie AI-Coding-Agents für die schwierigeren Rewrites. Ians internes Beispiel bei SELECT: Ein Datensatz, der bei jedem Lauf komplett neu erzeugt wurde, kostete über 8.000 $ pro Jahr – ein paar Stunden Arbeit, um die Query inkrementell zu machen, sparten diese Ausgaben ein. Er ergänzte, dass Coding-Agents wie Coco solche Rewrites heute in Stunden ermöglichen, wo früher Tage nötig waren.

Speziell zur Ingestion sagte Ian, dass sie typischerweise etwa 10 bis 20 % der Compute-Ausgaben ausmacht – Tendenz fallend. Snowpipe Streaming hat die Ingestion-Kosten bei einigen Kunden um rund das Zehnfache gesenkt, und auch die zunehmende Nutzung von Iceberg hilft. Daves zwei einfachste Ingestion-Einsparungen: Übernehmen Sie nur die Tabellen und Spalten, die Sie wirklich brauchen, und richten Sie die Aktualisierungsfrequenz am tatsächlichen Geschäftsbedarf aus, statt standardmäßig so nah wie möglich an Echtzeit zu gehen.

Verlagern Teams Workloads auf günstigere Engines wie DuckDB oder setzen sie auf Iceberg, um Geld zu sparen?

In kleinem Maßstab: manchmal. Ein einzelner Engineer in einem kleineren Unternehmen kann bestimmte Workloads durchaus auf etwas wie DuckDB umleiten. In großem Maßstab, mit Tausenden Nutzern, die zentrale Zugriffskontrollen brauchen, ist es selten – weil es zu schwer zu managen ist. Dave sagte, er habe Iceberg nie wirklich als Sparmaßnahme betrachtet. Sein Reiz liegt in der Interoperabilität: Dieselben Daten lassen sich von vielen Stellen aus wiederverwenden, ohne mehr Compute auszugeben. Ian ergänzte, dass Iceberg die Ingestion-Kosten senken kann und vermeidet, zweimal für Storage zu zahlen – mehrere Compute-Engines darauf zu betreiben, sehe er aber kaum. Dave sagte, häufiger sehe er Kunden, die ganze Workloads zwischen Plattformen verschieben, etwa von Snowflake zu Databricks oder von Postgres zu Snowflake und zurück, je nachdem, was besser passt. Für ihn geht es dabei darum, Compute zu sparen, nicht Storage zu optimieren.

Ein einzelnes zentrales Datenteam, das jede Kostenfrage beantwortet, skaliert nicht. Dave, der selbst in dieser Rolle war, beschrieb, wie ein kleines Team zum Flaschenhals wird, sobald jede Datenanfrage über es läuft. Die Lösung: Endnutzern Transparenz über die Kosten geben, die sie verursachen – damit alle verantwortungsvoll mit dem umgehen können, was sie ausgeben.

Das beginnt mit der Kostenallokation: Ausgaben den verantwortlichen Teams zuordnen, damit die Aufmerksamkeit der Beteiligten auf dem bleibt, was sie beeinflussen können. Unterschiedliche Zielgruppen brauchen zudem unterschiedliche Sichten. Führungskräfte wollen in der Regel übergeordnete Dashboards mit Kosten pro Gruppe über Tag, Woche oder Monat. Praktiker wollen die konkreten Dinge sehen, die ihr eigenes Team betreibt.

Diese Informationen leicht zugänglich zu machen, ist genauso wichtig wie sie überhaupt zu haben. Dave schlug vor, für jede Zielgruppe passende Dashboards zu bauen – oder Zugang zu einem MCP-Server zu geben, damit die Leute Claude die richtigen Fragen stellen können. Ian ergänzte, dass Nutzer manchmal einfach kuratierte Informationen in einer leicht bedienbaren Oberfläche brauchen: liefert sie mir, lasst mich nicht danach suchen.

Ein Center of Excellence hat eine echte, aber eng umrissene Rolle. Das zentrale Team sollte Nutzer dabei beraten, wie sie ihre Kosten verbessern, und dieses Wissen in der Organisation verbreiten – nicht die Verantwortung dafür übernehmen, jede Optimierung selbst durchzuführen. Wie Ian es formulierte: Diese Dinge einzeln im Namen der gesamten Organisation zu erledigen, bringt einen nur ein Stück weit.