Ratgeber & Vergleiche · Stand: 18. Oktober 2026

Snowflake-Kosten: Rechnung verstehen und Verbrauch steuern

Was Snowflake kostet, ergibt sich aus Ihrem Verbrauch und den dafür geltenden Preisen. Rechnen Sie Compute, Speicher und relevante Datenübertragungen getrennt. Für Compute sind Credits die Verbrauchseinheit; erst der zugehörige Preis macht daraus einen Geldbetrag. Ein günstiger Creditpreis allein sagt deshalb wenig über die Monatsrechnung aus.

Die wichtigste Vorarbeit ist eine Zuordnung: Welcher Dienst verursacht den Verbrauch, für welche Aufgabe läuft er, und wer darf eingreifen? Damit lässt sich eine Schätzung nachvollziehen und später mit der tatsächlichen Nutzung vergleichen.

Welche Kosten gehören auf die Rechnung?

Die Architektur erklärt einen Teil der Kostenverteilung: Snowflake hält Daten in einer Speicherschicht, verarbeitet sie unter anderem mit virtuellen Warehouses und koordiniert Zugriffe über Cloud Services. Dazu gehören etwa Authentifizierung, Metadatenverwaltung und Abfrageoptimierung. Speicher und Rechenleistung lassen sich dadurch getrennt betrachten. Weitere Dienste benötigen eine eigene Verbrauchszeile. Die offizielle Gesamtkostenübersicht unterscheidet Compute, Speicher und Datentransfer und weist ausdrücklich auf zusätzliche Kostenregeln etwa für Cortex und Container Services hin.

Ein virtuelles Warehouse ist hier eine Rechenressource, kein weiterer vollständiger Datenspeicher. Wenn Sie es anhalten, verschwinden die gespeicherten Daten und deren Kosten nicht. Ebenso endet damit nicht automatisch der Verbrauch anderer Dienste. Die folgende Kostenlandkarte trennt diese Bestandteile von den jeweiligen Kontrollmöglichkeiten.

Die Verbrauchsrechnung bildet außerdem nicht Ihre gesamten Projektkosten ab. Datenanbindung, Entwicklung, Migration, BI-Lizenzen und laufende Betreuung gehören in eine zusätzliche Betrachtung der Gesamtkosten, häufig als Total Cost of Ownership oder TCO bezeichnet.

Welcher Preis gilt für Ihren Verbrauch?

Halten Sie vor einer Kalkulation Cloudplattform, Region, Edition, Vertragsmodell, Währung und Preisstand fest. Snowflake bietet On-Demand-Nutzung und im Voraus vereinbarte Kapazität an. Verwenden Sie die für Ihren Vertrag geltenden Werte und dokumentieren Sie deren Datum. Eine Rechnung mit einem aus einem fremden Beispiel übernommenen Dollarpreis ist keine belastbare Schätzung.

Die Preis- und Editionsübersicht von Snowflake nennt vier Ausprägungen:

Diese Auswahl sollte aus Anforderungen folgen. Eine höhere Edition ist weder ein allgemeiner Wirtschaftlichkeitsnachweis noch ein automatischer Nachweis rechtlicher Konformität. Ein Preisrechner hilft beim Einsetzen bekannter Größen. Wie viel Ihr konkreter Bericht unter paralleler Last verbraucht, müssen Sie dennoch ermitteln.

Compute: Laufzeit, Dienste und Abrechnungsregeln trennen

Warehouse-Verbrauch entsteht auch im Leerlauf

Bei klassischen virtuellen Warehouses bestimmen Größe, laufende Clusterzahl und Laufzeit den Creditverbrauch. Die Nutzerzahl wirkt über die ausgelöste Arbeit und Parallelität; sie ist keine alleinige Verbrauchsgröße. Ein laufendes Warehouse verbraucht auch dann Credits, wenn gerade keine Abfrage arbeitet.

Bei jedem Start beziehungsweise jeder Wiederaufnahme gilt eine Mindestabrechnung von 60 Sekunden. Danach wird die fortlaufende Nutzung sekundengenau abgerechnet. Bei einer Vergrößerung gilt die Mindestabrechnung für die zusätzlich bereitgestellten Ressourcen. Häufiges Anhalten und Wiederaufnehmen innerhalb kurzer Zeit spart deshalb nicht einfach die Differenz zwischen SQL-Laufzeit und einer Minute. Diese Regeln beschreibt Snowflake unter Compute-Kosten.

Cloud Services sind kein pauschaler Aufschlag

Unterscheiden Sie gemessene Cloud-Services-Credits von den tatsächlich berechneten Credits. Snowflake ermittelt täglich in UTC eine Anpassung auf Basis von zehn Prozent des Warehouse-Verbrauchs. Diese wird höchstens bis zur tatsächlich angefallenen Cloud-Services-Nutzung angewandt. Serverless-Verbrauch zählt nicht zur Berechnungsbasis.

Zur Einordnung ein vereinfachtes Rechenbeispiel: Bei 100 Warehouse-Credits und 14 Cloud-Services-Credits an einem Tag beträgt die Anpassung 10 Credits; 4 Cloud-Services-Credits bleiben berechenbar. Bei nur 6 Cloud-Services-Credits wären diese vollständig durch die Anpassung abgedeckt. Das sind Modellwerte, keine Kontomessung. Entscheidend ist: Die Regel bedeutet keinen zehnprozentigen Aufschlag auf die Rechnung. Die Monatsanpassung ergibt sich aus den einzelnen Tagen, nicht aus einer beliebigen monatlichen Verrechnung.

Serverless, KI und Compute Pools benötigen eigene Zeilen

Bei Serverless-Funktionen verwaltet Snowflake die Rechenressourcen. Snowpipe, automatische Clusterpflege und Search Optimization sind Beispiele für gesondert zu betrachtende Nutzung. Prüfen Sie die aktuelle Berechnung des jeweiligen Dienstes und die zugehörige Service Consumption Table. Cloud Services, die bereits in der Rechnungsposition eines Serverless-Dienstes enthalten sind, dürfen Sie nicht noch einmal hinzufügen.

Erfassen Sie auch Cortex beziehungsweise Snowflake Intelligence und Container-Workloads. Bei Compute Pools beeinflussen Anzahl und Typ der verwendeten Rechenknoten den Verbrauch. Für KI benötigen Sie den konkreten Dienst, gegebenenfalls das Modell, die Nutzungsmenge, regionale Verfügbarkeit und die gültige Preisregel. Ein allgemeiner Warehouse-Stundensatz deckt diese Nutzung nicht pauschal ab. Ein gestopptes Analyse-Warehouse beendet sie ebenfalls nicht automatisch.

Speicher, Historie und Datenwege berücksichtigen

Die Quelldateigröße ist nicht die Speicherrechnung

Traditionelle Snowflake-Tabellen werden komprimiert gespeichert. Die grundlegende Monatsberechnung verwendet die durchschnittliche tägliche Belegung und den geltenden Speicherpreis. Eine unkomprimierte Quelldatei mit derselben Datenmenge kann daher eine andere Größe haben. Hinzu kommen beispielsweise Dateien in internen Stages, also Ablagen zum Laden oder Entladen von Daten.

Behandeln Sie unterschiedliche Speicherformen gesondert. Hybrid-Tabellen besitzen eigene Speicherpreisregeln. Bei extern gehaltenen Iceberg-Daten kommen die Zuständigkeit und Rechnung des Speicheranbieters hinzu. Auch bestimmte Zugriffe externer Engines über den Horizon Catalog auf Snowflake Storage können Requestgebühren auslösen. Eine einzige TB-Rate für sämtliche Speicher- und Zugriffsarten wäre zu grob. Die aktuelle Speicherkostendokumentation beschreibt diese Unterschiede.

Wiederherstellbarkeit hat einen Speicherumfang

Änderungen können historische Daten für Time Travel und Fail-safe erzeugen. Auch durch Klone zurückgehaltene Daten gehören in die Betrachtung. Ein Zero-copy-Klon teilt anfangs die bestehenden Datenblöcke; spätere Änderungen können zusätzlichen Speicher benötigen. Eine Entwicklungskopie ist damit nicht auf Dauer automatisch kostenlos.

Verändern Sie Aufbewahrung und Tabellentyp nur zusammen mit dem Wiederherstellungsbedarf. Transiente und temporäre Tabellen haben keinen Fail-safe und höchstens einen Tag Time Travel. Die häufig missverstandene Ein-Tages-Grenze betrifft die zusätzliche Historie: Aktive Daten bleiben während ihrer Speicherung kostenpflichtig. Für transiente Daten muss ein unabhängiger Wiederaufbau möglich sein, wenn ihre Wiederherstellungsfrist endet. Das erläutert Snowflake in den Kosten für Time Travel und Fail-safe.

Nicht jede Datenbewegung folgt derselben Transferregel

Prüfen Sie bei Ausleitung, Replikation und Freigaben über Regionen oder Cloudplattformen jeweils Quelle, Ziel und Dienst. Snowflake berechnet keinen Dateneingang. Der Quellanbieter kann jedoch Gebühren für den Ausgang aus seinem Netz erheben.

Für ausgehende Daten gelten abhängig vom Weg Transferregeln. Eine wichtige Ausnahme: Beim Abruf von Abfrageergebnissen durch Snowflake-Clients oder -Treiber erhebt Snowflake laut Datentransferdokumentation auch über Regions- oder Cloudgrenzen keine Egressgebühren. Daraus folgt keine Kostenfreiheit aller beteiligten Anbieter oder jedes anderen Datenwegs.

Ein nachvollziehbares Monatsmodell aufbauen

Nutzen Sie ein offenes Modell mit eigenen Eingaben. Für jede Position gilt zunächst: abrechenbare Menge × zugehöriger Vertragspreis. Warehouse-Credits, bereinigte Cloud-Services-Credits, weitere Dienste, durchschnittlicher Speicher und kostenpflichtige Transfers werden getrennt ermittelt. Führen Sie nur Positionen zusammen, für die dieselbe Preisregel gilt.

Die folgende Tabelle ist ein eigenes Planungsschema, keine Beispielrechnung eines Kunden:

Ergänzen Sie zu jeder Zeile den Preisbeleg mit Datum, den betrachteten Zeitraum und eine Kennzeichnung noch fehlender Werte. Rechnen Sie Normalbetrieb und realistische Lastspitzen getrennt. Ein Monatsbetrag, in dem noch unbekannte Dienste fehlen, sollte als unvollständige Schätzung sichtbar bleiben.

Ein Kurzstartmodell mit offengelegten Annahmen

Angenommen, ein einzelner Cluster startet sechsmal vollständig getrennt. Seine gesamte Laufzeit betrage jeweils 20 Sekunden. Für das Modell setzen wir frei gewählte 6 Credits pro Stunde an; dieser Wert ist kein Snowflake-Tarif und keine Zuordnung zu einer realen Warehouse-Größe.

Die berechnete Zeit beträgt im Modell 6 × max(20, 60) = 360 Sekunden. Daraus folgen 360 ÷ 3.600 × 6 = 0,6 Credits. Würden Sie nur die 120 angenommenen Laufzeitsekunden addieren, kämen Sie auf 0,2 Credits und unterschätzten die Mindestabrechnung.

Für echte Ausführungen müssen Sie die tatsächliche Ressourcenlaufzeit einschließlich relevanter Bereitstellungs- und Leerlaufzeiten sowie die laufenden Cluster erfassen. Das Modell weist diese Zeiten nicht als gemessene Null aus. Es zeigt den Mindestabrechnungseffekt, belegt aber keine Ersparnis gegenüber einem durchlaufenden Warehouse: Dafür fehlen die Abstände zwischen den Aufträgen und die Leistungsanforderungen.

Tatsächlichen Verbrauch untersuchen und gezielt verändern

Beginnen Sie in Snowsight mit einer berechtigten Rolle unter Admin → Cost management → Consumption. Wählen Sie einen nachvollziehbaren Zeitraum und trennen Sie die Usage Types. Für eigene Auswertungen stehen je nach Zugriff die Schemata ACCOUNT_USAGE und ORGANIZATION_USAGE bereit; zum Abgleich dient außerdem das Billing Statement.

Beachten Sie die Zeitgrenzen: Die Oberfläche verwendet UTC. Kosteninformationen können laut Dokumentation zur Kostenanalyse bis zu 72 Stunden verzögert erscheinen. Verfügbare Accountfilter und Geldbeträge hängen unter anderem von Berechtigungen und Vertragskonstellation ab. Die Ansicht ist kein verzögerungsfreier Rechnungsticker.

Ordnen Sie den auffälligen Verbrauch anschließend einer Ressource, einem Workload und einem fachlich verantwortlichen Team zu. Erst dann wählen Sie den Eingriff:

• Nutzungslücken: Auto-Suspend und Auto-Resume an die tatsächlichen Pausen und den Wiederanlaufbedarf anpassen. Ein zu kurzer Abstand kann häufige Neustarts verursachen.
• Einzelne aufwendige Abfragen: Filter, Joins, gelesene Datenmenge und Datenlayout untersuchen. Eine kleinere Warehouse-Konfiguration ist nicht automatisch wirtschaftlicher, wenn die Arbeit deutlich länger dauert.
• Viele gleichzeitige Abfragen: Größe und Clusterzahl getrennt betrachten. Mehr Ressourcen für eine Abfrage und zusätzliche Cluster für Parallelität behandeln verschiedene Engpässe.

Vergleichen Sie dabei dieselben fachlichen Ergebnisse. Dokumentieren Sie Laufzeit, Warteschlange, Creditverbrauch und Verhalten unter Spitzenlast. Automatische Optimierungsdienste können eigenen Verbrauch erzeugen; bewerten Sie die gesamte Veränderung.

Beim Suspendieren geht der lokale Datencache des Warehouses verloren. Nach dem Wiederanlauf kann dessen Neuaufbau die ersten Abfragen beeinflussen. Verwechseln Sie diesen Cache nicht mit persistierten Abfrageergebnissen. Snowflakes Warehouse-Empfehlungen behandeln die Abwägung zwischen Anhalten und Cache-Nutzung ausdrücklich. Eine pauschale Einstellung ohne Lasttest kann Kosten verschieben und zugleich die Antwortzeit verschlechtern.

Was Resource Monitors und Budgets tatsächlich steuern

Resource Monitors: Warehouse-Schwellen mit Betriebswirkung

Ein Resource Monitor muss dem Konto beziehungsweise konkreten Warehouses zugeordnet sein und eine Aktion besitzen. Er verfolgt deren Credits einschließlich der unterstützenden Cloud Services. Für die Schwellenberechnung wird die tägliche Cloud-Services-Anpassung nicht abgezogen. Der gezählte Wert kann deshalb von den später fakturierten Credits abweichen.

Die Aktionen haben unterschiedliche Folgen für klassische Warehouses: Notify benachrichtigt; Suspend lässt laufende Statements abschließen und hält anschließend an; Suspend Immediate bricht laufende Statements beim Anhalten ab. Prüfen Sie, welche Berichte und Ladeprozesse davon betroffen wären.

Ein Resource Monitor erfasst keine Serverless- oder KI-Dienste. Selbst eine sofortige Suspend-Aktion verhindert nicht kreditgenau jeden Restverbrauch; zudem können weitere Cloud-Services-Kosten entstehen. Diese Grenzen stehen in der Resource-Monitor-Dokumentation. Testen Sie Zuordnung, Empfänger, Eingriff und Wiederanlauf, bevor Sie die Kontrolle als betriebliche Begrenzung einplanen.

Budgets: Prognose und konfigurierte Aktionen

Budgets arbeiten mit monatlichen Creditgrenzen. Das Account Budget und Custom Budgets unterscheiden den Umfang der beobachteten Nutzung; für eigene Ressourcengruppen müssen die unterstützten Objekte und Dienste geprüft werden. Die Creditgrenze ist keine Obergrenze für die gesamte Speicher- und Transferrechnung.

Eine Prognosewarnung entsteht, wenn der Verbrauch voraussichtlich die Grenze überschreitet. Verbrauchsdaten kommen zeitverzögert an: Snowflake nennt für die Standardaktualisierung bis zu 6,5 Stunden und eine kostenintensivere Variante mit einer Stunde. Auch die Überwachung selbst verbraucht Ressourcen. Details und unterstützte Dienste nennt die Budgetdokumentation.

Budgets können darüber hinaus bei Ist- oder Prognoseschwellen eigene Stored Procedures aufrufen, beispielsweise zum Suspendieren von Warehouses. Die Aussage „Budgets warnen nur“ wäre daher zu eng. Solche Custom Actions benötigen passende Rechte, laufen mit den Rechten des Prozedureigentümers und müssen wiederholte Aufrufe vertragen. Prüfen Sie außerdem die Auslösung und ihre Kosten. Datenverzug, Auslösungsgrenzen und die Reichweite Ihrer Aktion bleiben bestehen: Ein allgemeiner unmittelbarer Stopp sämtlicher Kosten entsteht dadurch nicht.

Gesamtkosten und Eignung vor einer Bindung prüfen

Eine Vergleichsmessung sollte Ihre tatsächliche Last abbilden: etwa strukturierte Tabellen zusammen mit verschachteltem JSON, gebündelte und kontinuierliche Datenaufnahme, parallele Berichte und eine festgelegte Zielantwortzeit. Gleiche Datenmengen, Ergebnisse, Betriebszeiten und Parallelität sind Voraussetzung für einen brauchbaren Vergleich. Wenn die Plattformwahl noch offen ist, führt der bestehende Vergleich von Snowflake und Databricks zur übergeordneten Entscheidung.

Ergänzen Sie die Verbrauchsrechnung um Datenübernahme und Validierung, Schema- und SQL-Anpassungen, Rechtekonzept, BI- beziehungsweise Connectorlizenzen, Schulung und Betrieb. Snowflake übernimmt die zugrunde liegende Infrastruktur und deren Updates. Fachliche Datenqualität, passende Zugriffsentscheidungen, Modellierung und die Verantwortung für den laufenden Einsatz bleiben dennoch Aufgaben Ihres Vorhabens. Der dokumentierte Infrastrukturumfang hilft, diese Grenze zu ziehen.

Für deutsche Unternehmen gehören Standorte, tatsächliche Datenflüsse, Zugriffsmöglichkeiten, Vertrag und verbindliche Organisationsanforderungen vor die Preisentscheidung. Eine EU-Region oder höhere Edition ersetzt diese Gesamtprüfung nicht. Legen Sie zunächst fest, was erfüllt werden muss; erst dann lässt sich dessen Kostenwirkung kalkulieren.

Bei geringer, stark schwankender oder noch unbekannter Nutzung kann eine sofortige Kapazitätsbindung verfrüht sein. Auch zusätzliche Engineering- und Betriebsarbeit muss sich gegenüber dem erwarteten Nutzen rechtfertigen. Getrennt skalierbare Ressourcen und verwaltete Infrastruktur können passen, wenn die benötigten Workloads und Verantwortlichkeiten klar sind. Prüfen Sie Preis, Leistung und Planbarkeit zunächst an repräsentativer Nutzung.

Ihre erste Kostenprüfung abschließen

Fassen Sie die Entscheidung in einem gemeinsamen Arbeitsblatt zusammen. Dieses eigene Schema verbindet die Zahlen mit einer verantworteten Maßnahme:

Vereinbaren Sie für Abweichungen einen Empfänger, eine Reaktionsfrist und die Person, die eine Änderung freigibt. So bleiben ein auffälliger Verbrauch, eine mögliche Ursache und eine verantwortete Entscheidung miteinander verbunden. Wenn Sie diese Prüfung für Ihre Datenplattform konkretisieren möchten, unterstützt die Snowflake-Beratung von eBiz bei der Einordnung des Vorhabens und seiner offenen Architektur- und Betriebsfragen.