BigQuery: On-Demand vs Slot-Reservation — wann was wirklich Sinn macht

BigQuery wirkt zuerst wie das einfachste Data-Warehouse der Welt: keine Cluster, keine Reservierungen, 5 $ pro gescanntem Terabyte. Bezahle, was du nutzt. Bis dann die erste Monatsrechnung über 8.000 $ kommt, weil jemand SELECT * auf einer 2-TB-Tabelle ausgeführt hat. Mehrfach.

Slot-Reservierung ändert das Modell komplett. Hier die ehrliche Entscheidungshilfe.

TL;DR

• On-Demand ist billig, wenn Last sporadisch und unter Kontrolle ist. Killer-Risiko: ein einzelner falsch-getunter Query kann 100 € kosten.
• Editions / Capacity (Slot-Reservation) ist vorhersehbar und ab ~200 $ konstanter monatlicher On-Demand-Verbrauch günstiger.
• Autoscale in Editions ist der süße Mittelweg: ramp-up bei Last, ramp-down bei Idle. Aber nicht jede Edition unterstützt es.
• Faustregel: Wenn du >2 TB/Tag scannst, rechne die Edition durch. Wenn du <500 GB/Tag scannst, bleib bei On-Demand.

Das Modell verstehen

On-Demand

• 5 $ pro TB gescannte Daten (Stand 13.05.2026)
• Erste 1 TB / Monat / Projekt kostenlos (Free Tier)
• Storage 0,02 $/GB/Mo active (<90 Tage modified), 0,01 $/GB/Mo long-term
• Kein vorhergesagter Verbrauch, ad-hoc-friendly
• Achtung: wird komplett auf gescannte Bytes abgerechnet, unabhängig wie viele Zeilen zurückgegeben werden

Editions (Capacity)

Drei Stufen:

• Standard: $0,04 / Slot-Hour, kein ML/BI Engine
• Enterprise: $0,06 / Slot-Hour, ML + BI Engine + 5-Year-Time-Travel
• Enterprise Plus: $0,10 / Slot-Hour, +Multi-Region, +Private Link

100 Slots Enterprise = 6 $/h = ~4.300 €/Mo bei 24/7 mit 30 % Autoscale-Headroom je nach Setup.

Slots verstanden

Ein Slot ist ein logischer Compute-Unit. BigQuery wandelt eine Query in Stages, jede Stage benutzt N Slots parallel. Mehr Slots = schnellere Queries (bis zur Query-Parallelisierungs-Grenze).

Faustregel: kleine Queries brauchen 50–200 Slots, mittlere 500, große ETL-Jobs 2.000+.

Wann On-Demand günstiger ist

Beispiel-Szenarien, in denen On-Demand klar gewinnt:

In allen drei Fällen ist On-Demand 5–80× günstiger als die kleinste Slot-Reservierung. Editions macht hier keinen Sinn.

Wann Editions / Slot-Reservation günstiger ist

Ab ~30 TB/Tag gescantem Volumen wird Editions zwingend günstiger. Ab ~100 TB/Tag ist On-Demand finanzieller Wahnsinn.

Autoscale richtig nutzen

Editions-Autoscale erlaubt min/max-Slot-Range. Beispiel: min 100, max 500.

• BigQuery skaliert in 100er-Schritten
• Skalierung ist rapid (Sekunden), nicht minutengenau
• Idle-Zeiten ohne Queries werden nicht berechnet (nur die min- Reservierung läuft konstant)
• Autoscale verfügbar in Enterprise + Enterprise Plus, nicht Standard

Praxis-Konfiguration:

• Min = 0 Slots → vollständig nutzungsbasiert
• Min = 100 Slots → Baseline für planbare Workloads
• Max = 2–5× Min → Burst-Headroom

Mit min=0 max=500 Enterprise zahlst du nur, wenn Queries laufen. Das ist Editions-Pricing mit On-Demand-ähnlicher Kostenstruktur, aber ohne 5 $/TB-Scan-Risiko.

Die häufigsten Fehler

1. SELECT * auf Partitionierte Tabellen

Ohne WHERE date = ... scannt BQ alle Partitionen. Eine 5-Jahres-Tabelle mit 1 PB → eine SELECT * = 5 PB Scan = 25.000 €.

Mitigation:

• Partition-Filter im Schema erforderlich machen (require_partition_filter = true)
• Cost-Limits via Reservation
• Query-Review für >100 GB Scans

2. Cluster-Keys nicht gesetzt

Cluster-Keys reduzieren Scan-Volumen erheblich (bis 90 %). Eine falsch geclusterte Tabelle scannt mehr als nötig — bei On-Demand linear teurer.

3. Materialisierte Views nicht genutzt

Materialized Views cachen häufige Aggregationen und werden bei Queries automatisch genutzt. 5 $/TB scan auf einer MV ist oft 99 % günstiger als gegen die Basis-Tabelle.

4. Falsche Storage-Klasse

Daten älter als 90 Tage ohne Änderung sind automatisch "long-term storage" = 50 % Storage-Rabatt. Aber: jede Änderung resettet das. ETL-Pipelines, die alte Partitionen "berühren" ohne echte Änderung (z. B. INSERT OVERWRITE ganzer Tabellen), verschenken den Rabatt.

5. BI-Engine-Reservation vergessen

BI Engine cached In-Memory für Looker/Tableau-Workloads. Bei 50 € BI-Engine-Reservation kannst du 2.000 € Scan-Bill einsparen.

Migration On-Demand → Editions

Wenn deine On-Demand-Bill über 1.500 €/Mo wächst, plane:

1. Slot-Verbrauch messen: INFORMATION_SCHEMA.JOBS_BY_PROJECT gibt total_slot_ms. p50/p95/peak ermitteln.
2. Min/Max-Slots schätzen: p50 als Min, p95 als Max-Start.
3. Mit Autoscale starten, 2 Wochen monitoren.
4. Cost-Comparison im FinOps-Dashboard: vorher / nachher.

In Kunden-Engagements waren typische Einsparungen 40–60 % beim Wechsel On-Demand → Enterprise Autoscale, plus Kosten-Predictability als Bonus.

Cost-Caps und Sicherheitsnetze

Drei eingebaute Schutzmechanismen, die jede BigQuery-Org haben sollte:

1. Custom Quotas

Project- / User-Quota für gescannte Bytes pro Tag.

gcloud bigquery queries set-quota --query-bytes-billed-per-day=5TB

2. Maximum Bytes Billed pro Query

Setze einen Hard-Cap pro Query in der Query-Konfiguration:

-- Im SDK: jobConfig.maximumBytesBilled = 100GB

Query failt mit bytesBilledLimitExceeded, statt 5.000 € zu scannen.

3. Budget-Alerts

Cloud-Billing-Budgets + Pub/Sub-Notifier → Slack-Alert bei Schwellenwert.

Faustregeln zum Mitnehmen

Quellen

• BigQuery Pricing
• Best Practices for Cost Optimization
• BigQuery Editions Comparison
• INFORMATION_SCHEMA Slot Usage

Stand: 13. Mai 2026. BigQuery-Pricing wird selten geändert, aber Editions-Features (besonders Autoscale-Bounds) entwickeln sich weiter. Aktuelle Konditionen vor Reservation prüfen.