BigQuery Slots vs. On-Demand 2026

Q: Wie viele BigQuery Slots brauche ich?

Rechnen Sie SUM(total_slot_ms) / 3.600.000 aus INFORMATION_SCHEMA.JOBS_BY_PROJECT pro Stunde und wählen Sie die Baseline auf 60–70 % des Durchschnitts sowie das Autoscaling-Maximum auf 130–150 % des p95-Werts über die letzten 30 Tage.

Aktualisiert: 30. August 2026

BigQuery Slot-Reservierungen lohnen sich in der Regel ab einer konstanten Auslastung von rund 100 aktiven Slots oder etwa 320 TiB gescanntem Datenvolumen pro Monat – darunter ist das On-Demand-Modell mit 6,25 US-Dollar pro TiB fast immer günstiger. Ich vergleiche hier beide Abrechnungsmodelle mit den aktuellen 2026er Preisen der drei Editions (Standard, Enterprise, Enterprise Plus), zeige, wie sich der Slot-Bedarf sauber aus INFORMATION_SCHEMA.JOBS ableiten lässt, und erkläre die Autoscaling-Fallen, die ich in eigenen Migrationen (leider zwei davon schmerzhaft) selbst erlebt habe.

On-Demand kostet 6,25 US-Dollar pro TiB, Standard Edition ab 0,04 US-Dollar pro Slot-Stunde – der Break-Even liegt bei etwa 100 Baseline-Slots oder rund 320 TiB monatlich.
Flat-Rate und Flex Slots wurden am 5. Juli 2023 endgültig abgeschaltet; heute gibt es ausschließlich On-Demand oder die drei Editions.
Autoscaling skaliert in 50-Slot-Schritten mit einer Mindestabrechnung von 60 Sekunden. Falsch gewählte Maximalwerte treiben die Rechnung, nicht die Baseline.
Ein 3-Jahres-Commitment reduziert Enterprise-Slots um 40 %; kombiniert mit granularem Autoscaling sinken die Kosten laut Google um weitere 30–40 %.
Standard Edition ist bei 1.600 Slots gedeckelt und bietet keine Commitments. Für stabile Produktionslasten ist Enterprise fast immer die bessere Wahl.
Die größte Ersparnis bringt weiterhin Query-Optimierung: partitionierte Tabellen, materialisierte Sichten und SELECT ohne * senken beide Kostenmodelle drastisch.

Was sind BigQuery Slots?

Ein BigQuery Slot ist eine virtuelle Recheneinheit, die einen Bruchteil einer CPU, Arbeitsspeicher und Netzwerkkapazität für die parallele Ausführung einer SQL-Abfrage bereitstellt. Slots sind das interne Rechenmodell der Query Engine (Dremel), und jede Abfrage wird intern in tausende kleine Aufgaben zerlegt, die auf freien Slots landen. Wichtig zu verstehen: Sie kaufen nie Slots im klassischen Sinn wie eine EC2-Instanz, sondern reservieren eine bestimmte Kapazität für einen Zeitraum. Die tatsächliche Zuordnung zu den Abfragen übernimmt der Scheduler.

Im On-Demand-Modell weist Google Ihnen dynamisch bis zu 2.000 gleichzeitige Slots pro Projekt zu (mit temporärer Elastizität auf bis zu ~20.000), ohne dass Sie eine Reservierung besitzen müssen. Bezahlt wird ausschließlich das gescannte Datenvolumen. Bei Editions dagegen legen Sie eine Reservation an, ordnen ihr eine Baseline plus eine autoscalende Obergrenze zu und bezahlen pro Slot-Stunde. Der entscheidende Unterschied ist also nicht die Rechenleistung, sondern das Abrechnungsmodell: Bytes vs. Kapazität.

Das erklärt auch, warum eine schlechte Query in On-Demand teuer sein kann, aber Ihre Reservation nicht sprengt, während dieselbe Query in einem zu klein dimensionierten Reservation-Slot einfach warten muss und andere Jobs blockiert. Für eine tiefere Einführung in die Slot-Semantik lohnt sich die offizielle Slot-Dokumentation von Google Cloud.

On-Demand vs. Editions: Preisvergleich 2026

Die aktuellen 2026er Preise für die US-Multiregion sehen wie folgt aus. Alle Zahlen beziehen sich auf US-Dollar; für europäische Regionen (europe-west3 Frankfurt, europe-west4 Eemshaven) gelten in der Regel Aufschläge zwischen 10 % und 20 %.

Merkmal	On-Demand	Standard Edition	Enterprise Edition	Enterprise Plus
Abrechnungsbasis	Pro TiB gescannt	Slot-Stunde	Slot-Stunde	Slot-Stunde
Grundpreis (US)	6,25 USD / TiB	0,04 USD / Slot-h	0,06 USD / Slot-h	0,10 USD / Slot-h
1-Jahres-Commitment	–	Nicht verfügbar	≈ 20 % Rabatt	≈ 20 % Rabatt
3-Jahres-Commitment	–	Nicht verfügbar	≈ 40 % Rabatt	≈ 40 % Rabatt
Autoscaling	Automatisch (bis 2.000 Slots)	50-Slot-Schritte, max. 1.600	50-Slot-Schritte, unbegrenzt	50-Slot-Schritte, unbegrenzt
Idle Slot Sharing	–	Nein	Ja	Ja
BigQuery ML / BI Engine	Eingeschränkt	Nein	Ja	Ja
Cross-Region Disaster Recovery	–	Nein	Nein	Ja
Free Tier	1 TiB / Monat	–	–	–

Der oft übersehene Punkt: Standard Edition wirkt mit 0,04 USD pro Slot-Stunde günstig, bietet aber keine Commitment-Rabatte und ist bei 1.600 Slots hart gedeckelt. Für Produktionsworkloads, die stabile Kapazität brauchen, ist Enterprise trotz des höheren Grundpreises fast immer wirtschaftlicher, sobald Sie ein 1- oder 3-Jahres-Commitment abschließen können.

Wann lohnen sich Slot-Reservierungen?

Die harte Regel, die ich in vier Migrationen bestätigt gesehen habe: Slot-Reservierungen rechnen sich ab etwa 100 dauerhaft ausgelasteten Baseline-Slots oder rund 320 TiB monatlich gescanntem Datenvolumen. Alles darunter kostet in Editions mehr als in On-Demand, weil Sie Kapazität bezahlen, die Sie nachts und am Wochenende gar nicht nutzen.

Rechnen wir das einmal konkret durch. Ein Team scannt monatlich 50 TiB im On-Demand-Modell, das kostet 50 × 6,25 USD = 312,50 USD. 100 Baseline-Slots in Standard Edition kosten dagegen 100 × 0,04 × 730 h ≈ 2.920 USD monatlich. Selbst wenn Sie eine 3-Jahres-Enterprise-Reservation mit 40 % Rabatt annehmen, landen Sie bei 100 × 0,06 × 0,60 × 730 ≈ 2.628 USD. On-Demand ist hier um den Faktor 8 günstiger.

Interessant wird's ab dem Punkt, an dem Sie täglich mehrere hundert TiB scannen oder Ihre Query-Konkurrenz an das On-Demand-Limit von 2.000 gleichzeitigen Slots stößt. Bei einem meiner ehemaligen Arbeitgeber (mittelgroßes Data-Team, viele parallele dbt-Läufe) lag die reine On-Demand-Rechnung für den Warehouse-Layer bei etwa 46.000 USD monatlich. Mit einer 3-Jahres-Enterprise-Reservation und aggressiver Query-Optimierung sind wir bei 28.500 USD gelandet, bei gleicher Latenz und deutlich höherer Vorhersagbarkeit.

Ehrlich gesagt: Vorhersagbarkeit war für den CFO fast wichtiger als die absolute Ersparnis. Eine schwankende Rechnung zwischen 30k und 60k pro Monat lässt sich schlechter budgetieren als ein flacher Commitment.

Falls Sie AWS-Referenzwerte suchen, wie sich langfristige Compute-Commitments in einer anderen Cloud rechnen, hilft der Vergleich AWS Savings Plans vs. Reserved Instances 2026 als Analogie. Die Entscheidungsmechanik ist erstaunlich ähnlich.

BigQuery Editions im Überblick: Standard, Enterprise, Enterprise Plus

Die Wahl der Edition ist keine reine Preisentscheidung, sondern hängt an drei Faktoren: Sicherheitsanforderungen, Feature-Bedarf und der Frage, ob Sie Idle Slot Sharing brauchen. Idle Slot Sharing ist der Mechanismus, mit dem eine Reservation ungenutzte Slots temporär an eine andere Reservation im selben Projekt verleiht. Für heterogene Workloads (Batch nachts, Interactive tagsüber) kann das den Kapazitätsbedarf glatt halbieren.

Standard Edition

Standard eignet sich für kleine Analyseteams mit unregelmäßigem Bedarf oder als Sandbox neben einer bestehenden Enterprise-Reservation. Kein Commitment-Rabatt, kein Idle Slot Sharing, kein BigQuery ML. Die 1.600-Slot-Grenze ist der wichtigste Ausschlussgrund für Produktion.

Enterprise Edition

Enterprise ist der Sweet Spot für die meisten Data-Plattform-Teams. Sie erhalten CMEK-Verschlüsselung, Row-Level und Column-Level Security, BigQuery ML, BI Engine, Idle Slot Sharing und Commitment-Rabatte. Der Aufschlag gegenüber Standard (0,06 vs. 0,04 USD pro Slot-Stunde) amortisiert sich meist innerhalb weniger Wochen allein durch die Commitment-Rabatte.

Enterprise Plus

Enterprise Plus adressiert regulierte Branchen: Finanzdienstleister, Healthcare, Behörden. Cross-Region Disaster Recovery, das höchste SLA und Compliance-Zertifizierungen rechtfertigen die 0,10 USD pro Slot-Stunde nur, wenn ein Ausfall Sie mehr kostet als der Aufpreis. Ein weiterer Vorteil: In Regionen mit hoher Slot-Nachfrage priorisiert BigQuery die Kapazität in der Reihenfolge Enterprise-Plus-Baseline, dann Enterprise-Baseline, dann Enterprise-Plus-Autoscale, dann Enterprise-Autoscale, dann Standard/On-Demand. Wer in europe-west3 zu Peak-Zeiten Kapazitätsprobleme sieht, gewinnt mit Enterprise Plus messbare Reservierungssicherheit.

Autoscaling und Slot-Commitments richtig kombinieren

Autoscaling ist in Editions der Default und gleichzeitig die häufigste Kostenfalle. Die Mechanik: Sie definieren eine Baseline (Mindest-Slots, die Sie immer halten) und ein Maximum (Obergrenze, auf die der Autoscaler eskalieren darf). Baseline-Slots können Sie über ein 1- oder 3-Jahres-Commitment vergünstigen, alles darüber wird zum Flex-Preis pro Slot-Stunde abgerechnet, aber nur solange die Slots aktiv genutzt werden. Die Skalierungsschritte betragen 50 Slots, die Mindestabrechnung pro Autoscale-Event liegt bei 60 Sekunden.

Der Klassiker-Fehler: Teams setzen das Maximum "zur Sicherheit" auf 5.000 oder 10.000 Slots, weil sie den Autoscaler nicht bremsen wollen. Am ersten Montag der Migration läuft dann ein fehlkonfigurierter dbt-Run parallel zu einem Datenschema-Refresh, der Autoscaler eskaliert für zwei Stunden auf 4.800 Slots, und die Rechnung enthält plötzlich einen 500-USD-Ausreißer für einen einzigen Vormittag.

Genau diesen Bug habe ich in meinem letzten Projekt live erlebt. Setzen Sie das Maximum immer knapp über den beobachteten p95-Bedarf, nicht auf einen theoretischen Worst Case.

# Reservation mit sinnvoller Baseline/Max-Grenze anlegen
bq mk --project_id=my-analytics-prod \
  --location=europe-west3 \
  --reservation \
  --slots=200 \
  --autoscale_max_slots=600 \
  --edition=ENTERPRISE \
  prod-analytics-reservation

# Reservation einem Projekt/Ordner zuweisen
bq mk --project_id=my-analytics-prod \
  --location=europe-west3 \
  --reservation_assignment \
  --reservation_id=prod-analytics-reservation \
  --job_type=QUERY \
  --assignee_id=my-analytics-prod \
  --assignee_type=PROJECT

Die Faustregel, die sich bei uns bewährt hat: Baseline auf 60–70 % des durchschnittlichen Slot-Bedarfs, Maximum auf 130–150 % des p95. Damit committen Sie sich zum Rabattpreis auf einen realistischen Grundbedarf und lassen Autoscaling die tatsächlichen Peaks abfangen, ohne dass ein Ausreißer die Monatsrechnung sprengt.

Slot-Bedarf berechnen: die richtige Baseline finden

Bevor Sie eine Reservation kaufen, sollten Sie den tatsächlichen Slot-Bedarf aus Ihren bisherigen On-Demand-Jobs ableiten. Das geht sauber über INFORMATION_SCHEMA.JOBS_BY_PROJECT bzw. JOBS_BY_ORGANIZATION, die den Feldwert total_slot_ms pro Job enthalten. Das ist die kumulierte Slot-Zeit in Millisekunden.

Diese Abfrage gibt Ihnen den durchschnittlichen und den p95-Slot-Bedarf pro Stunde über die letzten 30 Tage:

-- Slot-Bedarf pro Stunde ableiten (letzte 30 Tage)
WITH per_hour AS (
  SELECT
    TIMESTAMP_TRUNC(creation_time, HOUR) AS hour_bucket,
    SUM(total_slot_ms) / (1000 * 60 * 60) AS avg_slots_used
  FROM `region-eu`.INFORMATION_SCHEMA.JOBS_BY_PROJECT
  WHERE creation_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
    AND statement_type IS NOT NULL
    AND state = 'DONE'
  GROUP BY hour_bucket
)
SELECT
  ROUND(AVG(avg_slots_used), 0) AS avg_hourly_slots,
  ROUND(APPROX_QUANTILES(avg_slots_used, 100)[OFFSET(50)], 0) AS p50_slots,
  ROUND(APPROX_QUANTILES(avg_slots_used, 100)[OFFSET(95)], 0) AS p95_slots,
  ROUND(APPROX_QUANTILES(avg_slots_used, 100)[OFFSET(99)], 0) AS p99_slots,
  ROUND(MAX(avg_slots_used), 0) AS max_slots
FROM per_hour;

Das Ergebnis liefert Ihnen vier Zahlen, mit denen Sie eine Reservation sinnvoll dimensionieren können. Ein typisches Ergebnis aus einem Analytics-Warehouse mittlerer Größe könnte so aussehen: avg 180, p50 140, p95 620, p99 950, max 1.400. Übersetzung: Setzen Sie die Baseline auf ~140 Slots (Commitment lohnt sich), das Autoscaling-Max auf ~800 Slots. Die Peaks über 800 blocken Sie bewusst weg. Sie sind meistens fehlkonfigurierte Batch-Jobs, keine legitimen Business-Anforderungen.

Für die konkrete Kostenmodellierung dividieren Sie den Slot-Bedarf pro Stunde durch den Preis pro Slot-Stunde und rechnen 730 Stunden pro Monat: 140 × 0,06 × 0,60 × 730 ≈ 3.680 USD/Monat bei Enterprise mit 3-Jahres-Commitment. Vergleichen Sie das mit den letzten drei Monatsrechnungen aus dem Billing-Export in BigQuery. Falls Sie noch keinen Billing-Export haben, richten Sie ihn zuerst ein, das ist die Grundlage jeder FinOps-Analyse.

Query-Optimierung ist die halbe Miete

Egal welches Preismodell Sie wählen: Der schnellste Weg, die BigQuery-Rechnung zu halbieren, ist Query-Optimierung. In On-Demand sparen Sie direkt Bytes, in Editions sparen Sie Slot-Zeit und damit die Autoscale-Eskalationen, die Ihre Peaks nach oben treiben. Drei Hebel sind besonders wirksam.

Partitionen und Cluster nutzen

Partitionierte Tabellen (nach DATE- oder TIMESTAMP-Spalten) reduzieren die gescannten Bytes auf den benötigten Zeitraum. Clustering ordnet die Daten physisch nach häufig gefilterten Spalten. Zusammen können sie den Scan-Umfang um mehr als 90 % reduzieren, aber nur, wenn die WHERE-Klausel den Partition-Filter auch explizit setzt.

-- Tabelle mit Partition und Clustering anlegen
CREATE TABLE analytics.events_v2
PARTITION BY DATE(event_timestamp)
CLUSTER BY user_id, event_type
AS SELECT * FROM analytics.events_v1;

-- Query, die den Partition-Filter nutzt
SELECT event_type, COUNT(*) AS n
FROM analytics.events_v2
WHERE DATE(event_timestamp) BETWEEN '2026-08-01' AND '2026-08-30'
  AND user_id IN (12345, 67890)
GROUP BY event_type;

Materialisierte Sichten für wiederkehrende Aggregate

Wenn ein Dashboard zwölf Mal pro Stunde dasselbe Aggregat aus einer 400-GiB-Tabelle liest, ist eine materialisierte Sicht in 30 Minuten amortisiert. BigQuery hält die Sicht automatisch inkrementell aktuell und rechnet den Refresh gegen Ihre Slots, nicht gegen die Bytes.

`SELECT *` vermeiden

Der schmerzhafteste Kostenfaktor in On-Demand ist SELECT * gegen eine breite Faktentabelle. BigQuery scannt jede Spalte, auch wenn Ihre Anwendung nur drei davon nutzt. Auf einer 2-TiB-Tabelle mit 200 Spalten zahlen Sie 12,50 USD statt 0,19 USD pro Abfrage. Klingt trivial, ist aber der häufigste Einzelposten, den ich in Kostenaudits sehe.

Wer tiefer in die Kostenattribution einsteigen möchte, insbesondere die Zuordnung auf Teams und Kostenstellen, findet Parallelen im Ansatz der AWS Cost Allocation Tags Multi-Account-Strategie. Auch in GCP wird die Sichtbarkeit erst mit konsequenten Labels auf Reservations, Datasets und Jobs zur belastbaren Grundlage.

Häufige Fallstricke bei der Migration von On-Demand

Vier Fehler sehe ich in fast jeder On-Demand-zu-Editions-Migration. Sie klingen banal, kosten aber im Extremfall den doppelten Monatsbetrag.

1. Reservation zu früh committen. Wer ohne 30-Tage-Baseline-Messung ein 3-Jahres-Commitment über 500 Slots kauft, zahlt drei Jahre lang für Kapazität, die er nie brauchte. Nutzen Sie die ersten 30–60 Tage im Pay-as-you-go-Modus der Editions, bevor Sie sich commiten. Ich hab genau diesen Fehler einmal gemacht und mich lange geärgert.

2. On-Demand-Projekte nicht sauber trennen. Ad-hoc-Analysen der Data Scientists sollten in einem eigenen Projekt ohne Reservation Assignment laufen. Sonst blocken sie Ihre Produktionsreservation und Sie zahlen doppelt: Slot-Reservation plus Autoscale-Peaks.

3. Idle Slot Sharing nicht aktivieren. In Enterprise ist Idle Slot Sharing standardmäßig aktiviert, aber viele Teams schalten es aus "Isolationsgründen" ab. Die Realität: In den meisten Setups nutzen Sie durchschnittlich nur 40 % Ihrer Baseline. Idle Slot Sharing verschenkt die restlichen 60 % an andere Reservations im selben Projekt und reduziert damit indirekt den Autoscale-Bedarf.

4. Kein Alerting auf ungewöhnliche Slot-Peaks. Setzen Sie einen Cloud-Monitoring-Alert auf bigquery.googleapis.com/slots/allocated_for_reservation, der Sie warnt, wenn die Reservation länger als 15 Minuten am Maximum kratzt. Das fängt fehlkonfigurierte Jobs, bevor sie sich zu vierstelligen Ausreißern summieren.

Wer eine parallele Perspektive auf Multi-Cloud-Rabattmodelle sucht, findet im Spot-Instanzen-Vergleich AWS vs. Azure vs. GCP eine gute Ergänzung. Slot Commitments in BigQuery sind das analytische Gegenstück zu Reserved Instances im Compute-Layer. Und für Teams, die BigQuery ML mit GPU-basierten Modellen kombinieren, ist mein Leitfaden zu GPU-Kosten für KI-Workloads senken die logische Fortsetzung.

Für die vollständige Preistabelle in allen Regionen und die aktuellen Autoscaling-Grenzwerte verweise ich auf die offizielle BigQuery-Preisdokumentation. Wer die Reservation-Semantik im Detail verstehen will, sollte ergänzend die Einführung in BigQuery Reservations lesen. Dort finden Sie auch die verbindlichen SLAs pro Edition.

Häufige Fragen

Was ist der Unterschied zwischen BigQuery On-Demand und Editions?

On-Demand rechnet nach gescannten Bytes ab (6,25 USD pro TiB), Editions nach reservierten Slot-Stunden (0,04–0,10 USD pro Slot-h). On-Demand ist günstiger für kleine, unregelmäßige Workloads; Editions lohnen sich ab etwa 100 dauerhaft ausgelasteten Slots.

Wie viele BigQuery Slots brauche ich?

Rechnen Sie SUM(total_slot_ms) / 3.600.000 aus INFORMATION_SCHEMA.JOBS_BY_PROJECT pro Stunde und wählen Sie die Baseline auf 60–70 % des Durchschnitts sowie das Autoscaling-Maximum auf 130–150 % des p95-Werts über die letzten 30 Tage.

Gibt es BigQuery Flat-Rate-Slots noch?

Nein. Google hat Flat-Rate-Slots und Flex Slots am 5. Juli 2023 abgeschaltet. Seitdem existieren ausschließlich das On-Demand-Modell und die drei Editions (Standard, Enterprise, Enterprise Plus) mit Slot-Stunden-Abrechnung.

Welche Edition ist die richtige für mein Team?

Standard eignet sich als Sandbox oder für kleine Teams unter 1.600 Slots. Enterprise ist der Standard für Produktions-Analytics-Workloads. Enterprise Plus lohnt sich nur bei strikten Compliance-Anforderungen oder wenn Sie Cross-Region Disaster Recovery brauchen.

Wie viel spart ein 3-Jahres-Commitment bei BigQuery?

Ein 3-Jahres-Commitment in Enterprise oder Enterprise Plus reduziert den Slot-Preis um etwa 40 %. Kombiniert mit granularem Autoscaling schätzt Google zusätzliche Einsparungen von 30–40 % beim Kapazitätsbedarf, da Sie nur die Baseline committen und Peaks flexibel abfangen.