Snowflake Kosten optimieren: 20-40 % Einsparung in 8 Schritten

Snowflakes verbrauchsbasiertes Pricing-Modell ist in der Theorie elegant — du zahlst nur, was du nutzt. In der Praxis stellen die meisten Data-Teams fest, dass ihre Snowflake-Rechnung Quartal für Quartal um 30-50 % wächst, ohne klare Erklärung. Snowflake-Kostenoptimierung heißt nicht, an Qualität zu sparen — sie heißt, zu verstehen, wo Compute- und Storage-Euros tatsächlich hinfließen und stille Verschwendung zu eliminieren.

Dieses Tutorial geht durch die wirkungsvollsten Hebel — mit SQL, das du heute gegen dein SNOWFLAKE.ACCOUNT_USAGE-Schema ausführen kannst.

TL;DR — Das 80/20 der Snowflake-Kosten

Compute ist, wo das Geld hinfließt. Start dort.

Schritt 1: Verstehe deinen Verbrauch mit Account Usage

Bevor du etwas optimierst, brauchst du Sichtbarkeit. Snowflake liefert das ACCOUNT_USAGE-Schema in der geteilten SNOWFLAKE-Datenbank — eine Goldmine für Kostenanalyse.

Finde deine teuersten Warehouses

-- Snowflake SQL
-- Credit consumption by warehouse (last 30 days)
SELECT
    warehouse_name,
    ROUND(SUM(credits_used), 2) AS total_credits,
    ROUND(SUM(credits_used) * 3.00, 2) AS estimated_cost_usd,
    COUNT(DISTINCT DATE_TRUNC('day', start_time)) AS active_days,
    ROUND(AVG(credits_used_compute), 4) AS avg_credits_per_interval
FROM snowflake.account_usage.warehouse_metering_history
WHERE start_time >= DATEADD('day', -30, CURRENT_TIMESTAMP())
GROUP BY warehouse_name
ORDER BY total_credits DESC;

Hinweis: $3,00/Credit ist der Standard-On-Demand-Tarif für Enterprise Edition. Dein Vertragspreis kann abweichen. Stand: Mai 2026.

Diese eine Query zeigt oft, dass 2-3 Warehouses 80 %+ des Verbrauchs ausmachen. Fokussiere deine Optimierung dort.

Finde Idle-Warehouse-Zeit

-- Snowflake SQL
-- Warehouses running but doing nothing (last 7 days)
SELECT
    warehouse_name,
    DATE_TRUNC('hour', start_time) AS hour_slot,
    SUM(credits_used) AS credits,
    SUM(credits_used_compute) AS compute_credits,
    SUM(credits_used_cloud_services) AS cloud_credits,
    CASE
        WHEN SUM(credits_used_compute) = 0 AND SUM(credits_used) > 0
        THEN 'IDLE_BURNING'
        ELSE 'ACTIVE'
    END AS status
FROM snowflake.account_usage.warehouse_metering_history
WHERE start_time >= DATEADD('day', -7, CURRENT_TIMESTAMP())
GROUP BY warehouse_name, hour_slot
HAVING status = 'IDLE_BURNING'
ORDER BY credits DESC;

Siehst du Warehouses regelmäßig im IDLE_BURNING-Status, brauchen deine Auto-Suspend-Einstellungen Aufmerksamkeit.

Schritt 2: Right-Size deine Warehouses

Der häufigste Fehler: ein X-Large-Warehouse "zur Sicherheit" wählen und nie revidieren. Snowflake-Warehouses skalieren linear — ein XL kostet 4× ein Small pro Sekunde.

Der Right-Sizing-Prozess

1. Profile deine Workloads — Lauf die Query oben, identifiziere die Top-Kostentreiber-Warehouses
2. Prüfe Queue-Zeiten — Queuen Queries nicht, ist dein Warehouse wahrscheinlich überdimensioniert
3. Test eine Größe kleiner — Reduziere die Warehouse-Größe und messe den Impact auf die Query-Dauer
4. Akzeptiere sinnvolle Trade-offs — Eine Query in 45 s statt 30 s spart 50 % auf diesem Warehouse

-- Snowflake SQL
-- Check if queries are queuing (indicates undersized warehouse)
SELECT
    warehouse_name,
    COUNT(*) AS total_queries,
    AVG(queued_overload_time) / 1000 AS avg_queue_seconds,
    MAX(queued_overload_time) / 1000 AS max_queue_seconds,
    COUNT_IF(queued_overload_time > 0) AS queued_query_count
FROM snowflake.account_usage.query_history
WHERE start_time >= DATEADD('day', -7, CURRENT_TIMESTAMP())
    AND warehouse_name IS NOT NULL
GROUP BY warehouse_name
ORDER BY avg_queue_seconds DESC;

Faustregel: Ist avg_queue_seconds 0 und queued_query_count 0, bist du wahrscheinlich überdimensioniert. Übersteigt avg_queue_seconds 10 s, musst du eventuell hochskalieren oder Multi-Cluster-Warehouses nutzen.

Schritt 3: Auto-Suspend und Auto-Resume

Das ist die Optimierung mit dem höchsten ROI für die meisten Teams. Der Default für Auto-Suspend ist 10 Minuten — das sind 10 Minuten Credit-Verbrennen nach jeder letzten Query.

Empfohlene Settings nach Workload

-- Snowflake SQL
-- Set aggressive auto-suspend for an ETL warehouse
ALTER WAREHOUSE ETL_WH SET
    AUTO_SUSPEND = 60
    AUTO_RESUME = TRUE;

-- Check current settings for all warehouses
SHOW WAREHOUSES;

Die 60-Sekunden-Regel: Wenn du keinen spezifischen Grund für länger hast, setz Auto-Suspend auf 60 Sekunden. Snowflake rechnet pro Sekunde (Mindestabrechnung 60 s), also zahlst du bei 60 s Auto-Suspend maximal eine zusätzliche Minute nach deiner letzten Query.

Schritt 4: Query-Optimierung — keine schlechte SQL mehr bezahlen

Compute-Kosten sind direkt proportional zu Query-Laufzeit × Warehouse-Größe. Schnellere Queries = niedrigere Rechnungen.

Finde deine teuersten Queries

-- Snowflake SQL
-- Top 20 most expensive queries (last 14 days)
SELECT
    query_id,
    query_text,
    warehouse_name,
    user_name,
    ROUND(total_elapsed_time / 1000, 2) AS duration_seconds,
    ROUND(credits_used_cloud_services, 4) AS cloud_credits,
    bytes_scanned / POWER(1024, 3) AS gb_scanned,
    partitions_scanned,
    partitions_total,
    ROUND(partitions_scanned / NULLIF(partitions_total, 0) * 100, 1) AS pct_partitions_scanned
FROM snowflake.account_usage.query_history
WHERE start_time >= DATEADD('day', -14, CURRENT_TIMESTAMP())
    AND total_elapsed_time > 0
    AND warehouse_name IS NOT NULL
ORDER BY total_elapsed_time DESC
LIMIT 20;

Die Spalte pct_partitions_scanned ist der Schlüssel. Scannt eine Query 90 %+ Partitionen auf einer großen Tabelle, fehlt vermutlich ein Clustering Key oder Filter.

Häufige Query-Anti-Patterns und Fixes

SELECT * auf großen Tabellen — Selektiere nur die Spalten, die du brauchst. Snowflakes Columnar Storage macht ungenutzte Spalten kostenlos, wenn du sie nicht selektierst.

Fehlende Filter auf Cluster-Spalten — Ist eine Tabelle nach event_date geclustert, filtere immer nach Datumsbereich. Ohne Filter scannt Snowflake jede Micro-Partition.

Wiederholte Subqueries — Nutz CTEs oder Temporary Tables statt dieselbe Subquery mehrmals laufen zu lassen.

-- Snowflake SQL
-- BAD: Scanning everything, selecting everything
SELECT * FROM events WHERE category = 'purchase';

-- BETTER: Filter on cluster key, select only needed columns
SELECT event_id, user_id, amount, event_timestamp
FROM events
WHERE event_date >= DATEADD('day', -7, CURRENT_DATE())
    AND category = 'purchase';

Schritt 5: Clustering Keys — Partitionen prunen, Credits sparen

Clustering Keys sagen Snowflake, wie Micro-Partitionen organisiert werden. Gut gewählte Keys reduzieren die pro Query gescannten Daten drastisch.

-- Snowflake SQL
-- Check clustering efficiency
SELECT
    table_name,
    clustering_key,
    ROUND(average_overlaps, 2) AS avg_overlaps,
    ROUND(average_depth, 2) AS avg_depth
FROM snowflake.account_usage.table_storage_metrics
WHERE clustering_key IS NOT NULL
    AND deleted IS NULL
ORDER BY average_depth DESC;

Wann clustern:

• Tabellen größer 1 TB (kleinere profitieren selten)
• Queries filtern konsistent auf dieselben 1-3 Spalten
• pct_partitions_scanned ist trotz Filter konsistent hoch

Wann NICHT clustern:

• Tabellen unter 100 GB
• Sehr zufällige Zugriffsmuster
• Tabellen, die meist nur angehängt und selten abgefragt werden

Achtung: Automatic Clustering ist ein Serverless-Feature und konsumiert Credits. Monitor das.

Schritt 6: Storage-Optimierung

Storage ist günstiger als Compute, summiert sich aber — besonders mit Snowflakes Default-Settings für Time Travel und Fail-safe.

Transient Tables für Staging

-- Snowflake SQL
-- Transient tables: no Fail-safe, Time Travel up to 1 day
CREATE TRANSIENT TABLE staging.raw_events (
    event_id STRING,
    payload VARIANT,
    loaded_at TIMESTAMP_NTZ DEFAULT CURRENT_TIMESTAMP()
)
DATA_RETENTION_TIME_IN_DAYS = 0;

Transient Tables überspringen die 7-tägige Fail-safe-Periode komplett. Für Staging-Daten, die ohnehin reloadet werden, eliminiert das unnötige Storage-Kosten.

Finde Storage-Verschwendung

-- Snowflake SQL
-- Tables consuming the most storage (including Time Travel + Fail-safe)
SELECT
    table_catalog AS database_name,
    table_schema AS schema_name,
    table_name,
    ROUND(active_bytes / POWER(1024, 3), 2) AS active_gb,
    ROUND(time_travel_bytes / POWER(1024, 3), 2) AS time_travel_gb,
    ROUND(failsafe_bytes / POWER(1024, 3), 2) AS failsafe_gb,
    ROUND((active_bytes + time_travel_bytes + failsafe_bytes) / POWER(1024, 3), 2) AS total_gb
FROM snowflake.account_usage.table_storage_metrics
WHERE deleted IS NULL
ORDER BY total_gb DESC
LIMIT 20;

Schritt 7: Resource Monitors — Leitplanken setzen

Betreibe nie einen Snowflake-Account ohne Resource Monitors. Sie sind kostenlos zu erstellen und verhindern Runaway-Kosten.

-- Snowflake SQL
-- Create a monthly resource monitor with alerts and hard stop
CREATE RESOURCE MONITOR monthly_budget
    WITH CREDIT_QUOTA = 5000
    FREQUENCY = MONTHLY
    START_TIMESTAMP = IMMEDIATELY
    TRIGGERS
        ON 75 PERCENT DO NOTIFY
        ON 90 PERCENT DO NOTIFY
        ON 100 PERCENT DO SUSPEND
        ON 110 PERCENT DO SUSPEND_IMMEDIATE;

-- Assign to a warehouse
ALTER WAREHOUSE ANALYTICS_WH SET RESOURCE_MONITOR = monthly_budget;

Best Practice: Separate Resource Monitors pro Warehouse oder Team erstellen. Ein globaler Monitor fängt Katastrophen, aber Per-Warehouse-Monitors geben dir Granularität.

Schritt 8: Serverless-Features monitoren

Snowflakes Serverless-Features (Automatic Clustering, Materialized Views, Search Optimization, Snowpipe) verbrauchen Credits still. Sie tauchen nicht im Warehouse-Metering auf.

-- Snowflake SQL
-- Monitor serverless credit consumption (last 30 days)
SELECT
    service_type,
    ROUND(SUM(credits_used), 2) AS total_credits,
    ROUND(SUM(credits_used) * 3.00, 2) AS estimated_cost_usd
FROM snowflake.account_usage.serverless_task_history
WHERE start_time >= DATEADD('day', -30, CURRENT_TIMESTAMP())
GROUP BY service_type
ORDER BY total_credits DESC;

Ist AUTOMATIC_CLUSTERING dein Top-Serverless-Kostentreiber, frage dich, ob alle geclusterten Tabellen wirklich vom Clustering profitieren. Entferne Clustering Keys von Tabellen, bei denen die Query-Muster den Maintenance-Overhead nicht rechtfertigen.

Häufige Fehler

1. "Sicherheits-Oversizing" — Start small, scale up nur wenn Queries queuen. Eine 2-Minuten-Query auf einem Small ist günstiger als 30 s auf einem X-Large.
2. Auto-Suspend bei 10 Minuten lassen — Ändere das am ersten Tag. 60 Sekunden ist fast immer der richtige Default.
3. ACCOUNT_USAGE ignorieren — Es ist kostenlos, umfassend und sagt dir genau, wo Geld hinfließt. Query es wöchentlich.
4. Kleine Tabellen clustern — Automatic Clustering kostet Credits. Auf Tabellen unter 100 GB übersteigen die Clustering-Kosten oft die Query-Einsparungen.
5. Keine Transient Tables für Staging — Jede permanente Tabelle zahlt 7 Tage Fail-safe-Storage. Staging-Daten brauchen das nicht.
6. Dieselbe teure Query mehrfach laufen lassen — Nutze RESULT_SCAN(LAST_QUERY_ID()) für schnelle Wiederabfragen oder materialisiere Ergebnisse in eine Tabelle.
7. Serverless-Kosten ignorieren — Unsichtbar im Warehouse-Metering, aber auf deiner Rechnung. Monatlich monitoren.

Ein Cost-Dashboard bauen

Kombiniere die Queries oben in einer Scheduled Task, die eine Cost-Tracking-Tabelle befüllt. Hier das Skelett:

-- Snowflake SQL
-- Create a daily cost snapshot table
CREATE TABLE IF NOT EXISTS monitoring.daily_cost_snapshot (
    snapshot_date DATE,
    warehouse_name STRING,
    credits_used FLOAT,
    estimated_cost_usd FLOAT,
    top_query_count INTEGER,
    avg_query_duration_seconds FLOAT
);

-- Populate daily (run via Snowflake Task or external scheduler)
INSERT INTO monitoring.daily_cost_snapshot
SELECT
    CURRENT_DATE() AS snapshot_date,
    wh.warehouse_name,
    ROUND(SUM(wh.credits_used), 2) AS credits_used,
    ROUND(SUM(wh.credits_used) * 3.00, 2) AS estimated_cost_usd,
    COUNT(DISTINCT qh.query_id) AS top_query_count,
    ROUND(AVG(qh.total_elapsed_time) / 1000, 2) AS avg_query_duration_seconds
FROM snowflake.account_usage.warehouse_metering_history wh
LEFT JOIN snowflake.account_usage.query_history qh
    ON wh.warehouse_name = qh.warehouse_name
    AND DATE_TRUNC('day', qh.start_time) = CURRENT_DATE() - 1
WHERE DATE_TRUNC('day', wh.start_time) = CURRENT_DATE() - 1
GROUP BY wh.warehouse_name;

Für Teams, die ihre Snowflake-Usage-Daten interaktiv erkunden wollen, lässt Harbinger Explorer dich SQL gegen exportierte Cost-Daten direkt im Browser per DuckDB WASM ausführen — praktisch für Ad-hoc-Analyse ohne laufendes Warehouse, besonders um Queries zu prototypen, bevor du sie in Snowflake deployst.

Nächste Schritte

Starte mit Schritt 1 — lass die Warehouse-Metering-Query laufen und identifiziere deine Top-3-Kostentreiber. Setz dann Auto-Suspend auf 60 Sekunden für jedes Nicht-Streaming-Warehouse. Diese zwei Änderungen sparen typischerweise 15-25 % auf deiner nächsten Rechnung.

Für laufende Optimierung: Schedule die Cost-Snapshot-Query täglich und reviewe Trends wöchentlich. Cost Creep ist schleichend — frühes Erkennen ist das ganze Spiel.

FAQ

Wie viel kann ich realistisch in Snowflake sparen?

20-40 % sind für die meisten Teams machbar, ohne die Performance einzubüßen. Die größten Hebel: Auto-Suspend von 10 min auf 60 s setzen, überdimensionierte Warehouses runterstufen, Transient Tables für Staging nutzen.

Brauche ich für DSGVO-Compliance eine bestimmte Snowflake-Region?

Für personenbezogene Daten aus der EU solltest du eine EU-Region nutzen (z. B. eu-central-1 Frankfurt oder eu-west-1 Dublin). Snowflake bietet Standard Contractual Clauses (SCCs) und einen AVV. Cross-Region-Replikation kann DSGVO-Themen aufmachen — kläre Datenresidenz pro Workload.

Was kostet ein Snowflake-Credit aktuell?

Standard On-Demand für Enterprise ist $3,00 pro Credit (Stand Mai 2026), Standard Edition liegt bei $2,00. Reserved Capacity und Multi-Year-Verträge können das auf $1,90-$2,50 senken. Prüfe deine Vertragspreise — die Account-Manager-Verhandlung lohnt sich bei höheren Volumen.

Wann lohnt sich ein Wechsel weg von Snowflake?

Bei vorhersehbarer, konstanter Last (z. B. Streaming-ETL rund um die Uhr) sind Databricks SQL Warehouses oder BigQuery oft günstiger. Bei sehr variabler Ad-hoc-Analytics-Last spielt Snowflakes Auto-Suspend-Modell seine Stärke aus. Mach den TCO-Vergleich für deine konkrete Workload.

Weiterlesen

• ETL vs ELT: Welcher Ansatz passt zu deinem Data Stack?
• Data Pipeline Monitoring
• Databricks vs Snowflake vs BigQuery

Stand: 15. Mai 2026.