TL;DR: Das Preismodell von BigQuery hat sich im Juli 2023 grundlegend geändert. Flat-Rate gibt es nicht mehr – an seine Stelle sind drei Editions-Stufen mit autoskalierenden Slots getreten. Die meisten vor 2023 verfassten Kostenleitfäden sind damit überholt, und Optimierungsprojekte, die als einmaliger Fix gedacht sind, greifen für 2026 zu kurz. Dieser Artikel zeigt, wie das BigQuery-Pricing heute wirklich funktioniert, welche Maßnahmen die Rechnung tatsächlich senken und wie sich Kostenprobleme erkennen lassen, bevor sie auf der Abrechnung auftauchen.
Die meisten BigQuery-Kostenprobleme machen sich auf die ungünstigste Weise bemerkbar: ein überraschender Posten in der letzten Monatsabrechnung, ein Data-Team-Lead, der den Screenshot eines Ausreißers weiterleitet, eine Frage aus dem Finanzbereich, die niemand schnell beantworten kann. Wenn das Gespräch beginnt, lief die verursachende Abfrage längst vor zwei Wochen.
Diese Erkennungslücke ist kein Tooling-Problem, sondern ein strukturelles. BigQuery rechnet im Nachhinein ab, Optimierung konkurriert mit der Roadmap, und das Preismodell hat sich seit dem Erscheinen der meisten Kostenleitfäden so stark verändert, dass viele Standard-Tipps schlicht nicht mehr passen. Engineers, die sich an Anleitungen mit Verweisen auf Flat-Rate-Slots oder 50-Slot-Autoscaling-Inkremente orientieren, tunen gegen ein Modell, das es gar nicht mehr gibt.
Dieser Leitfaden zeigt, wie BigQuery-Kostenoptimierung 2026 wirklich aussieht: das aktuelle Preismodell, die Maßnahmen, die Kosten senken, ohne die Performance zu beeinträchtigen, und die Observability-Ebene, die kontinuierliche Verbesserung erst möglich macht.
Warum BigQuery-Kostenoptimierung 2026 anders aussieht
Das Wichtigste zum BigQuery-Pricing 2026: Flat-Rate ist Geschichte. Google hat Flat-Rate-Slot-Käufe und Flex Slots am 5. Juli 2023 eingestellt und durch ein dreistufiges Modell namens Editions ersetzt – Standard, Enterprise und Enterprise Plus. On-Demand-Pricing gibt es weiterhin, doch die Kapazitätsseite von BigQuery funktioniert heute anders, als es die meisten Dokumentationen beschreiben.
Autoskalierende Slots sind unter Editions das Standard-Kapazitätsmodell. Statt einen festen Slot-Block pro Monat zu kaufen, konfigurieren Sie eine Baseline (den Sockel, den Sie immer halten) und ein Maximum (die Obergrenze, bis zu der der Autoscaler hochfahren darf). BigQuery skaliert je nach Abfrageaufkommen zwischen diesen Grenzen und rechnet pro Slot-Stunde ab, nicht gegen einen festen Block. Die praktische Folge: Das Kostenrisiko skaliert mit der Nutzung, nicht mit einem vorab getätigten Kauf. Damit wird Optimierung zu einer Daueraufgabe statt zu einer einmaligen Provisionierungsentscheidung.
Dieser Wechsel ist entscheidend dafür, wie Engineering-Teams Kostenarbeit angehen sollten. Er erweitert auch den Umfang dessen, was beobachtet werden muss. BigQuery-Kostenoptimierung 2026 heißt, neben dem Kern-Compute auch Nebendienste zu berücksichtigen: Cloud Composer v3 (speziell Version 3, die ein neues Abrechnungsmodell mitbringt) und Dataplex verursachen beide Gebühren, die unter BigQuery-nahen SKUs auftauchen und die Gesamtkosten einer Datenplattform in die Höhe treiben. Teams, die eine Kosteninitiative aufsetzen, sollten die Abrechnungsdaten für diese Services von Anfang an gemeinsam mit dem BigQuery-Compute auswerten und sie nicht als separate Aufräumaufgabe behandeln.
Eine Tabelle zu partitionieren hilft nach wie vor, doch die Einsparungsrechnung sieht bei autoskalierenden Slots anders aus als unter Flat-Rate. Workloads zu staffeln, um unter einer Slot-Commitment-Schwelle zu bleiben, war 2022 die richtige Antwort; 2026 geht es darum, die Slot-Stunden, die Ihre workloads überhaupt verbrauchen, zu reduzieren und Baseline sowie Obergrenze an die tatsächlichen Lastmuster anzupassen. Optimierung ist kontinuierliches Tuning, kein Projekt, das man abschließt.
Wie BigQuery-Pricing tatsächlich funktioniert
BigQuery rechnet zwei Dinge unabhängig voneinander ab: Compute und Storage. Compute verdient die meiste Aufmerksamkeit bei der Optimierung, denn dort skalieren die Kosten unvorhersehbar.
On-Demand-Pricing
On-Demand rechnet pro gescanntem Tebibyte ab: 6,25 USD pro TiB, wobei das erste TiB pro Monat und Projekt kostenlos ist. Slots kaufen Sie nicht direkt; Google stellt im Hintergrund bis zu 2.000 geteilte Slots pro Projekt bereit. On-Demand passt gut zu Teams mit unregelmäßigem oder geringem Abfragevolumen, zu Entwicklungs- und Testumgebungen sowie zu Ad-hoc-Analyse-workloads, deren Abfragemuster nicht vorhersehbar sind. Das Risiko liegt bei den Scankosten: Eine schlecht geschriebene Abfrage gegen eine große, nicht partitionierte Tabelle kann mit einem einzigen Job erhebliche Kosten verursachen.
Editions: Slot-basiertes Pricing
Editions rechnet pro Slot-Stunde ab: die Anzahl der Slots, die Ihre Reservierung verfügbar macht, multipliziert mit der Dauer, über die sie gehalten werden. In der US-Region liegen die Pay-as-you-go-Raten bei 0,04 USD pro Slot-Stunde für Standard, 0,06 USD für Enterprise und 0,10 USD für Enterprise Plus. Enterprise und Enterprise Plus bieten zusätzlich 1- und 3-jährige Slot-Commitments zu vergünstigten Raten. Unabhängig von diesen Kapazitäts-Commitments gibt es bei Google außerdem ausgabenbasierte Committed Use Discounts (CUDs): 10 % Rabatt bei einem 1-jährigen Ausgaben-Commitment, 20 % bei einem 3-jährigen – jeweils auf alle berechtigten BigQuery-PAYG-Nutzungen in einer Region.
Autoscaling unter Editions skaliert in 50-Slot-Inkrementen (nicht 100, wie ältere Dokumentationen es beschreiben) – mit einem Standard-Mindestabrechnungsfenster von 60 Sekunden pro Autoscaling-Ereignis. Diese 60-Sekunden-Untergrenze ist das Scale-Down-Fenster des Autoscalers, keine Regel pro Abfrage. Eine kurze Burst-Abfrage, die Autoscaling auslöst, verursacht standardmäßig dennoch mindestens eine Minute Gebühren auf diesen zusätzlichen Slots. Google hat dafür ein Opt-in-Feature namens Fluid Scaling eingeführt, inzwischen allgemein verfügbar, das die 60-Sekunden-Untergrenze durch echte sekundengenaue Abrechnung auf Reservierungsebene ersetzt. Teams mit kurzen, hochfrequenten oder variablen Abfragen sollten prüfen, ob Fluid Scaling ihre effektiven Slot-Stunden-Kosten senkt.
Die Break-even-Rechnung zwischen On-Demand und Editions ist aussagekräftiger, wenn man sie an der Enterprise Edition festmacht – dem für die meisten Produktionsteams relevanteren Vergleich. Die Standard Edition deckelt bei 1.600 Slots pro Reservierung und bietet weder CMEK noch BI-Engine-Integration noch mehrjährige Commitments, was beim Verlagern vorhersehbarer workloads weg von On-Demand oft Ausschlusskriterien sind. Zu 0,06 USD pro Slot-Stunde kosten 100 Enterprise-Edition-Slots, die einen Monat durchlaufen, rund 4.380 USD – das entspricht etwa 700 TiB On-Demand-Scan zu 6,25 USD pro TiB. Scannt Ihr Team konstant weniger mit unvorhersehbarem Timing, ist On-Demand vermutlich günstiger. Scannen Sie mehr oder ballen sich Ihre workloads in vorhersehbaren Zeitfenstern, dürfte das Slot-Pricing von Editions vorne liegen. Der einzig verlässliche Weg, Ihren tatsächlichen Break-even zu berechnen, ist eine Abfrage auf INFORMATION_SCHEMA.JOBS für die gesamten Slot-Millisekunden der letzten 30 bis 90 Tage und deren Umrechnung in Slot-Stunden.
Storage-Pricing
BigQuery bietet zwei Storage-Abrechnungsmodelle auf Dataset-Ebene: logical und physical. Logical Storage, der Standard, rechnet auf Basis unkomprimierter Bytes ab. Physical Storage rechnet auf Basis komprimierter Bytes ab, und da BigQuery die Daten vor der Abrechnung komprimiert, ist die reine Rate pro GiB niedriger. Der Haken: Physical Storage erfordert mittlerweile die Bezahlung von Time Travel und sieben Tagen Fail-Safe-Storage zum Active-Physical-Tarif – Kosten, die unter Logical Billing nicht anfallen. Bei Datasets mit hohen Kompressionsraten gewinnt das Physical-Modell in der Gesamtrechnung trotzdem; bei anderen können Time Travel und Fail-Safe-Overhead das Bild kippen. Nutzen Sie die Storage-Billing-Vergleichsabfrage aus der DoiT BigQuery Optimization Query Library (github.com/doitintl/bigquery-optimization-queries), um vor dem Umstieg die Nettoempfehlung für jedes Dataset zu berechnen. Active Storage und Long-Term Storage (Tabellen oder Partitionen, die 90 Tage lang nicht verändert wurden) haben in beiden Modellen unterschiedliche Raten, wobei Long-Term Storage etwa die Hälfte des Active-Tarifs kostet. Ungenutzte Tabellen und alte Partitionen, die wegen beiläufiger Schreibzugriffe nie in den Long-Term-Status wechseln, sind ein typischer versteckter Kostenfaktor.
Zuweisung des Preismodells
Ein Detail, das leicht übersehen wird: Das Preismodell wird pro Reservierungszuweisung gewählt, nicht pro Organisation. Verschiedene Projekte oder Ordner innerhalb derselben Google-Cloud-Organisation können gleichzeitig auf unterschiedlichen Modellen laufen. Ein Entwicklungsprojekt kann auf On-Demand bleiben, während Produktions-workloads auf Enterprise-Edition-Slots laufen. Diese Flexibilität pro Projekt heißt: Sie müssen keine Alles-oder-nichts-Entscheidung für die gesamte Organisation treffen.
ModellAbrechnungseinheitUS-Pay-as-you-go-RateBeste EignungOn-DemandTiB gescannt6,25 USD / TiBUnregelmäßige, geringe oder unvorhersehbare workloadsStandard EditionSlot-Stunde0,04 USD / Slot-StdAnalytics-Teams mit konstantem, mittlerem Volumen; kein Commitment erforderlichEnterprise EditionSlot-Stunde0,06 USD / Slot-StdProduktions-workloads mit Anforderungen an Sicherheit, Governance oder BI-Engine-IntegrationEnterprise PlusSlot-Stunde0,10 USD / Slot-StdGeschäftskritische workloads mit regionsübergreifendem DR oder Compliance-Anforderungen
BigQuery-Optimierungstaktiken, die die Rechnung senken
Die folgenden Maßnahmen senken die BigQuery-Kosten – egal ob Sie auf On-Demand oder Editions setzen. Bei On-Demand bedeuten weniger gescannte Bytes direkt eine niedrigere Rechnung. Bei Editions bedeutet effizientere Abfrageausführung weniger verbrauchte Slot-Stunden, was wiederum die Kosten Ihrer Autoscaling-Obergrenze und Ihres Baseline-Commitments senkt.
Das richtige Storage-Abrechnungsmodell wählen
Physical Storage Billing ist einer der wirkungsstärksten Kostenhebel in BigQuery – und einer der am häufigsten übersehenen. BigQuery bietet zwei Storage-Abrechnungsmodelle auf Dataset-Ebene: logical (der historische Standard, abgerechnet auf unkomprimierte Bytes) und physical (abgerechnet auf komprimierte Bytes). Physical Storage kostet pro GiB rund das Doppelte der Logical-Rate, doch da BigQuery die Daten vor der Abrechnung komprimiert, sind die effektiven Kosten für die meisten workloads niedriger.
Die Einsparungen hängen vollständig von Ihrer Kompressionsrate ab. BigQuery verwendet einen generischen Kompressionsalgorithmus, nicht einen spaltenweise auf bestimmte Datentypen zugeschnittenen. Workloads mit hochentropischen Daten wie Logs, Event-Streams oder textlastigen Datensätzen komprimieren unter diesem Algorithmus oft im Verhältnis 10:1 oder besser, wodurch Physical Storage deutlich günstiger wird. Workloads, die von festen numerischen Typen wie Integern, Doubles und Floats dominiert werden, bieten einem generischen Algorithmus dagegen kaum strukturelle Redundanz und komprimieren entsprechend schlecht – hier kann Physical Billing am Ende teurer ausfallen als Logical. Lassen Sie die Storage-Billing-Vergleichsabfrage gegen Ihr Projekt laufen, bevor Sie ein Dataset umstellen: Sie zeigt Ihre aktuellen Kosten, die prognostizierten Kosten unter dem anderen Modell und eine Empfehlung pro Dataset. Das Modell wird auf Dataset-Ebene gesetzt, nicht auf Projektebene – wertvolle Datasets lassen sich also einzeln umstellen, ohne den Rest anzutasten.
Für Daten, die Sie gesetzlich aufbewahren müssen, aber selten oder nie abfragen, sollten Sie stattdessen einen Export nach Google Cloud Storage Coldline oder Archive in Erwägung ziehen. Ein Dataset mit siebenjähriger HIPAA-Aufbewahrungspflicht, das in BigQuery liegt, verursacht unbefristet Active- oder Long-Term-Storage-Gebühren. Dieselben Daten in einem GCS-Archive-Bucket kosten einen Bruchteil davon, bleiben bei Bedarf über externe BigQuery-Tabellen abfragbar und werden automatisch gelöscht, wenn die Aufbewahrungsfrist abläuft – sofern Sie Lifecycle-Regeln konfigurieren.
Tabellen partitionieren, um weniger Daten zu scannen
Partitionierung teilt eine große Tabelle in kleinere Segmente, üblicherweise nach Datum oder einer Spalte mit hoher Kardinalität, sodass Abfragen die nicht benötigten Partitionen überspringen können. Die Technik wirkt nur, wenn Abfragen einen qualifizierenden Filter auf die Partitionsspalte enthalten. Eine Abfrage gegen eine partitionierte Tabelle ohne Filter auf den Partitionsschlüssel scannt die gesamte Tabelle – als gäbe es keine Partitionierung.
Die praktische Priorität: Partitionieren Sie Tabellen, die eine Zeitdimension tragen und von Dashboards oder geplanten Jobs mit Datumsbereichen abgefragt werden. Eine Abfrage auf INFORMATION_SCHEMA.JOBS_BY_PROJECT, gefiltert nach total_bytes_processed, deckt Tabellen auf, in denen wiederkehrende Jobs ohne Partitionsfilter laufen. Das ist der schnellste Weg zur Scanreduktion.
Tabellen clustern für feinkörnigeres Pruning
Clustering ordnet die Daten einer Tabelle in Blöcken nach den Werten einer oder mehrerer Spalten. Abfragen, die nach diesen Spalten filtern, überspringen die nicht passenden Blöcke und reduzieren so die gescannten Bytes über das hinaus, was Partitionierung allein erreicht. Clustering wirkt am besten bei Spalten mit hoher Kardinalität, die häufig in WHERE-Klauseln oder JOIN-Bedingungen auftreten, und die Spaltenreihenfolge in der Cluster-Definition sollte die Filterreihenfolge der Abfragen widerspiegeln.
Partitionierung und Clustering lassen sich kombinieren. Die Kombination ist sinnvoll bei großen Tabellen, die sowohl nach einer Zeitdimension als auch nach einer sekundären Filterspalte abgefragt werden – etwa einer Tenant-ID oder einem Event-Typ. Der Haken: Kombinierte Strategien erhöhen den Metadaten-Overhead, und der Clustering-Vorteil schrumpft, wenn Abfragen nicht konsequent in der definierten Reihenfolge auf dieselben Spalten filtern.
Früh filtern und gezielt selektieren
BigQuery rechnet auf Basis der vor den Filtern gescannten Bytes ab – ein SELECT * gegen eine breite Tabelle stellt also jede Spalte in Rechnung, unabhängig davon, welche Spalten das Ergebnis tatsächlich verwendet. Nur die benötigten Spalten auszuwählen und Partitions- sowie Clusterfilter früh in der Abfrage anzuwenden, reduziert das Scanvolumen direkt. Subqueries, die breite Tabellen referenzieren, ziehen die vollen Scankosten durch, selbst wenn die äußere Abfrage nur wenige Spalten projiziert.
Die Query-Einstellung maximum_bytes_billed erlaubt eine harte Obergrenze für das Scanvolumen einer einzelnen Abfrage. Jede Abfrage, die das Limit überschreiten würde, scheitert sofort, statt durchzulaufen und hohe Kosten zu erzeugen. Diese Einstellung wirkt zugleich als Kostenleitplanke während der Entwicklung und als Sicherheitsnetz in der Produktion – für Jobs, bei denen eine außer Kontrolle geratene Abfrage teuer wäre.
Autoscaling-Slot-Baselines und -Obergrenzen feinjustieren
Unter Editions steuern Sie zwei Slot-Parameter pro Reservierung: die Baseline (immer verfügbare Slots) und das Maximum (die Obergrenze, bis zu der der Autoscaler hochfahren darf). Autoscaling fügt in 50-Slot-Inkrementen Kapazität hinzu, wenn die Nachfrage die Baseline übersteigt – mit einem Scale-Down-Fenster von standardmäßig 60 Sekunden, bevor die Slots wieder freigegeben werden. Ein Job, der Autoscaling auch nur für eine Sekunde auslöst, verursacht unter Standard-Autoscaling eine volle Minute Abrechnung auf diesen 50 zusätzlichen Slots. Aktivieren Sie Fluid Scaling auf Reservierungsebene, wechselt BigQuery zu echter sekundengenauer Abrechnung ohne Mindestdauer – laut Google können dadurch die Kosten für workloads mit kurzen oder variablen Abfragemustern um bis zu 34 % sinken. Die 50-Slot-Inkrementgröße ändert sich unter Fluid Scaling nicht.
Ein zu hoch gesetztes Maximum bedeutet, dass kurze Burst-Jobs unnötig in teures Terrain ausschlagen können. Eine zu niedrige Baseline bedeutet, dass die meisten workloads auf autoskalierter Kapazität laufen, die pro Slot-Stunde teurer ist als committete Baseline-Slots, sobald Enterprise- oder Enterprise-Plus-Commitments im Spiel sind. Das Optimierungsziel ist eine Baseline, die den Sockel Ihres Steady-State-Workloads abdeckt, und eine Obergrenze, die legitime Spitzen abfängt, ohne Spielraum für entgleiste Jobs zu lassen.
Fragen Sie INFORMATION_SCHEMA.JOBS für die letzten 60 Tage ab, um den tatsächlichen gleichzeitigen Slot-Verbrauch pro Tagesstunde zu kartieren. Diese Verteilung sagt Ihnen, wo die Baseline und wo die Obergrenze liegen sollten. Für den Migrationspfad von On-Demand deckt der fünfschrittige Migrationsleitfaden von DoiT das Reservierungs-Setup vollständig ab.
Ein operatives Muster, das bei vorhersehbaren workloads die Kosten senkt: Skalieren Sie Ihre Reservierung dynamisch rund um bekannte ETL-Fenster. Die Baseline vor einem schweren nächtlichen Transform-Job hochziehen, nach dessen Abschluss wieder absenken. So müssen Sie teure Slots nicht durch die Leerlaufstunden vor und nach dem Job halten. Umgekehrt funktioniert derselbe Ansatz für Teams, die tagsüber Headroom brauchen, nachts aber kaum workloads fahren.
Ausgabenbasierte CUDs auf Ihr Preismodell aufsetzen
Wenn Sie sich für ein Projekt auf Editions festgelegt haben, lohnt sich ein zweiter Rabattmechanismus: ausgabenbasierte Committed Use Discounts. Diese sind unabhängig von Slot-Kapazitäts-Commitments. Statt sich auf eine feste Slot-Zahl festzulegen, verpflichten Sie sich zu einem stündlichen Mindestbetrag an BigQuery-Ausgaben in einer bestimmten Region – und Google wendet einen Rabatt auf alle berechtigten PAYG-Nutzungen an, die durch das Commitment abgedeckt sind.
Aktuelle Rabattsätze: 10 % bei einer Laufzeit von 1 Jahr, 20 % bei 3 Jahren. Der Rabatt gilt automatisch für alle BigQuery-PAYG-Compute-Typen in der committeten Region, ohne manuelle Slot-Allokation. Nutzung oberhalb des committeten Stundenbetrags wird zur Standard-PAYG-Rate berechnet; bei Nutzung darunter wird der Commitment-Betrag dennoch in voller Höhe abgerechnet. Das Commitment ist nicht stornierbar – dimensionieren Sie es daher an Ihren erwarteten stündlichen Mindestausgaben, nicht am Durchschnitt, um nicht für Kapazität zu zahlen, die in ruhigeren Phasen brachliegt.
Eine operative Falle: Slot-Commitments unter Editions verlängern sich standardmäßig automatisch. Ein auf weitere drei Jahre eingestelltes Commitment verlängert sich still und leise, sofern Sie die Verlängerungseinstellung nicht vor dem Ablauffenster prüfen und anpassen. Google erlaubt Stornierungen in der Regel innerhalb von sieben Tagen nach einer Verlängerung – danach nicht mehr. Prüfen Sie die Verlängerungseinstellungen Ihrer Commitments im Rahmen jedes routinemäßigen Abrechnungsaudits.
Pro Projekt zwischen On-Demand und Editions entscheiden
Da die Zuweisung des Preismodells pro Projekt erfolgt, ist es richtig, Projekte einzeln zu prüfen, statt eine Einheitslösung für die gesamte Organisation zu suchen. Entwicklungs-, Test- und Ad-hoc-Analystenprojekte passen oft zu On-Demand; nächtliche ETL-Pipelines, Dashboard-Backends und wiederkehrende Datenprodukte mit vorhersehbarem Slot-Verbrauch sprechen typischerweise für Editions.
Das Signal, auf das Sie achten sollten: Ein Projekt, in dem der durchschnittliche Slot-Verbrauch konstant über 50 Slots liegt, ist eine Prüfung für Editions wert. Ein Projekt, in dem sich die Slot-Spitzen in einem vorhersehbaren Tagesfenster bündeln, etwa bei einem nächtlichen Transform-Job, ist ein starker Kandidat für ein Baseline-Commitment. Projekte mit volatiler oder sporadischer Nutzung sollten auf On-Demand bleiben, wo der geteilte Slot-Pool in Leerlaufphasen nichts kostet. Eine vollständige Aufschlüsselung zur Bewertung des Wechsels finden Sie im BigQuery-Editions-Leitfaden von DoiT sowie im Autoscaling-Überblick.
Wiederholte Dashboard- und BI-Tool-Abfragen mit BI Engine cachen
Looker und dbt sind in Kundenumgebungen durchweg die beiden größten Kostentreiber im BigQuery-Compute. Das Muster ist in beiden Fällen identisch: Ein BI-Tool oder eine Transformationsschicht greift hunderte oder tausende Male pro Tag auf dieselben Tabellen zu, jede Abfrage scannt dieselben Daten und wird entsprechend abgerechnet. Die Scankosten summieren sich – egal ob auf On-Demand oder Editions.
BI Engine ist die In-Memory-Caching-Schicht von BigQuery. Sie sitzt vor dem BigQuery-Storage, fängt Abfragen ab, die sie aus dem Cache bedienen kann, und liefert Ergebnisse, ohne einen vollständigen Scan auszulösen. Sie reservieren eine feste Menge Speicher (abgerechnet pro GB-Stunde), legen bevorzugte Tabellen fest, die warm gehalten werden sollen, und BI Engine übernimmt Cache-Befüllung und -Invalidierung automatisch. Cache-Treffer laufen schneller und kosten nichts über die Reservierungsgebühr hinaus.
Die ROI-Rechnung ist geradlinig: Ermitteln Sie, welchen Service-Account Ihr BI-Tool nutzt, messen Sie, wie viele Daten es pro Tag gegen welche Tabellen scannt, und vergleichen Sie diese Scankosten mit einer BI-Engine-Reservierung, die diese Tabellen im Speicher hält. Für workloads, die wiederholt dieselben großen Tabellen mit geringfügigen Datumsbereichsvariationen treffen, ist die Reservierungsgebühr typischerweise ein Bruchteil der ersetzten Scankosten. BI-Engine-Reservierungen lassen sich bei Bedarf in der Größe anpassen oder löschen – Sie binden sich also nicht an ein festes Commitment.
Materialized Views ergänzen BI Engine bei aggregationslastigen Abfragen. Wenn ein Dashboard wiederholt dieselbe Summe, denselben Durchschnitt oder dieselbe Anzahl über ein großes Dataset berechnet, berechnet eine Materialized View dieses Aggregat vorab und speichert das Ergebnis. Folgende Abfragen lesen den vorab berechneten Wert, statt ihn bei jeder Ausführung neu zu berechnen. Kombiniert mit BI-Engine-Caching eliminieren beide Techniken den größten Teil der redundanten Rechenarbeit, die BI-Tools in BigQuery-Umgebungen teuer macht.
Frequenz geplanter und wiederkehrender Jobs reduzieren
Geplante Abfragen, die häufiger laufen, als Konsumenten das Ergebnis tatsächlich brauchen, sind in beiden Preismodellen direkter Waste. Ein Dashboard, das stündlich aktualisiert, aber zweimal täglich angesehen wird, trägt das Sechsfache der eigentlich nötigen Compute-Kosten. Ein Report, der nächtlich läuft, aber in ein wöchentliches Business Review fließt, könnte ebenso gut wöchentlich laufen.
Das Gespräch ist genauso organisatorisch wie technisch. Eine Abfrage auf INFORMATION_SCHEMA.JOBS, gefiltert nach Jobfrequenz und verarbeiteten Bytes, liefert Engineering-Teams die Datenbasis, um eine Frequenzreduktion zu begründen, ohne die Auswirkungen raten zu müssen. Hochfrequente Jobs, die große Volumina scannen und Konsumenten bedienen, die die Ergebnisse selten prüfen, sind die Ziele mit dem höchsten Hebel. Einen breiteren Kontext zur CloudOps-Kostenoptimierung liefert das Framework von DoiT, das beschreibt, wie Teams diese Art laufender Governance-Arbeit strukturieren.
Ungenutzte Tabellen und Partitionen sichern und löschen
Tabellen, die monatelang nicht abgefragt wurden, verursachen weiterhin Active-Storage-Gebühren, sofern sie irgendwelche Schreibzugriffe erhalten – auch beiläufige, die den 90-Tage-Long-Term-Storage-Zähler zurücksetzen. Partitionen innerhalb aktiver Tabellen, die außerhalb sinnvoller Abfragebereiche liegen, erzeugen Scankosten, wenn Abfragen nicht korrekt filtern. Beides lässt sich über Partitions-Ablaufrichtlinien und regelmäßige Tabellenaudits adressieren.
Die Ansicht INFORMATION_SCHEMA.TABLE_STORAGE in BigQuery zeigt Tabellengröße, letzten Änderungszeitpunkt und Zeilenanzahl auf Projektebene. Tabellen, die groß, alt und nie abgefragt sind, sind Kandidaten für Archivierung oder Löschung. Eine Partitions-Ablauffrist bei der Tabellenerstellung verhindert die langfristige Ansammlung veralteter Daten, ohne dass laufende manuelle Aufräumarbeiten nötig sind.
So decken Sie BigQuery-Kostenprobleme auf, bevor sie auf der Rechnung landen
Die strukturelle Herausforderung bei der BigQuery-Kosten-Observability ist, dass die Standard-Tools Ihnen Historie liefern, keine Alerts. Cloud Monitoring und INFORMATION_SCHEMA sagen Ihnen, was passiert ist; sie unterbrechen keine laufende teure Arbeit und melden keine Anomalien, während diese entstehen.
Mehrere native Kontrollen bringen Sie näher an eine proaktive Erkennung. Der Parameter maximum_bytes_billed auf Query-Ebene verhindert, dass einzelne entglittene Abfragen durchlaufen. Slot-Usage-Alerts in Cloud Monitoring schlagen aus, wenn der Slot-Verbrauch einer Reservierung eine Schwelle überschreitet, und decken so unerwartete Last auf, selbst wenn die Abfrage selbst unauffällig wirkt. Cloud Functions oder Cloud Workflows können raffiniertere Alert-Logik umsetzen – etwa eine Benachrichtigung, wenn der Slot-Verbrauch eines bestimmten Projekts seinen rollierenden Durchschnitt um einen konfigurierbaren Schwellwert überschreitet.
Auf regionsübergreifenden Egress zwischen Compute und Storage achten
Google hat das Label "multi-region" in BigQuery kürzlich abgekündigt – es war ohnehin lange irreführend. Was als US-Multi-Region bezeichnet wurde, liegt physisch ganz überwiegend in us-central-1; was als EU-Multi-Region bezeichnet wurde, typischerweise in europe-west-4. Wenn Ihr Dataset in einer einzelnen Region wie us-east-1 liegt und Ihr Compute gegen die US-Region läuft – oder umgekehrt – berechnet Google bei jedem Lesevorgang regionsübergreifenden Egress. Diese Gebühren erscheinen als separate Posten in der Billing-Konsole unter SKUs, die viele Engineers nicht sofort als Egress erkennen.
Die Erkennungsmethode: Durchsuchen Sie Ihren Billing-Export nach SKUs, die dem Muster "General Data Transfer Networking Traffic for Google Cloud Cross Region/Inter Region" entsprechen. Erscheint diese SKU in Ihrem Export, ist regionsübergreifender Egress nachgewiesen. Um die Quelle aufzuspüren, suchen Sie nach Analysis- oder Editions-Compute-SKUs neben Storage-SKUs unterschiedlicher Regionen im selben Abrechnungszeitraum. Die Kombination zeigt, welche Compute-Region aus welcher Storage-Region liest. Die Korrektur ist geradlinig: Storage und Compute in derselben Region zusammenlegen.
Unerwartete Dataplex- und Data-Lineage-API-Gebühren prüfen
Dataplex und die Data Lineage API erzeugen Gebühren, die in der Billing-Konsole unter Dataplex-SKUs erscheinen, und viele Teams zahlen sie, ohne zu wissen, dass die Services aktiv sind. Dataplex kann automatisch durch Integrationen, Dataset-Konfigurationen oder Trial-Features aktiviert werden und scannt und katalogisiert Daten im Hintergrund weiter – unabhängig davon, ob der Katalog aktiv genutzt wird. Die Data Lineage API kann, selbst wenn sie unabhängig von Dataplex aktiviert wurde, in bestimmten Konfigurationen Dataplex-Billing auslösen.
Wenn Sie in Ihrem Billing-Export Gebühren für Dataplex Premium Processing Units sehen und Ihr Team Dataplex nicht aktiv für Datenerkundung, Lineage oder Governance einsetzt, prüfen Sie, welche APIs aktiviert sind und ob Integrationen sie eingeschaltet haben. Das Deaktivieren sowohl der Dataplex API als auch der Data Lineage API in Projekten, in denen sie nicht gebraucht werden, eliminiert die Hintergrundgebühren vollständig. Mehrere kostenlose und Open-Source-Tools decken Data Lineage ab, ohne Dataplex-Billing auszulösen.
Anomalien auf Job-Ebene erkennen, nicht nur auf Reservierungsebene
Die Lücke in den nativen Tools ist die Anomalieerkennung auf Job-Ebene. Cloud Monitoring arbeitet auf Reservierungsebene; es kann melden, dass der Slot-Verbrauch ausgeschlagen hat, aber nicht, welcher Job den Ausschlag verursacht hat, zu welchem Projekt er gehört oder ob das Muster ein Einmal-Ereignis oder eine wiederkehrende Regression ist. Vom Slot-Ausschlag zum verantwortlichen Job zu kommen, erfordert manuellen Abgleich mit INFORMATION_SCHEMA.JOBS – und das kostet Zeit, die das Team im Moment meist nicht hat.
Diese Lücke zu schließen, erfordert ein zeitgesteuertes Abfragen von INFORMATION_SCHEMA.JOBS, den Vergleich der Slot-Millisekunden und verarbeiteten Bytes jedes Jobs mit dessen rollierendem historischen Durchschnitt und Alerts, sobald ein Job einen konfigurierbaren Schwellwert überschreitet. Das Field-Data-Engineering-Team von DoiT kann diese Erkennungsschicht für Teams umsetzen, die sie brauchen – ohne den Overhead, die Pipeline intern aufzubauen und zu pflegen. Mehr zum frühzeitigen Erkennen von Kostenspitzen vor der Rechnung lesen Sie im DoiT-Beitrag zur BigQuery-Kostenspitzenerkennung.
Wann sich BigQuery-Kostenoptimierung automatisieren lässt
Manuelle Optimierung skaliert nur bis zu einem gewissen Punkt. Ein Engineering-Team, das eine Handvoll BigQuery-Projekte betreut, kann Schlüsseltabellen partitionieren, Reservierungseinstellungen tunen und geplante Jobs in einem vernünftigen Rhythmus prüfen. Dasselbe Team, das 40 Projekte über mehrere Geschäftsbereiche hinweg betreut, kann mit Optimierungsarbeit neben der Feature-Entwicklung nicht Schritt halten. Der Backlog wächst schneller, als die Arbeit erledigt wird.
Bei der Automatisierung geht es nicht darum, Engineering-Urteilsvermögen zu ersetzen. Es geht darum sicherzustellen, dass dieses Urteilsvermögen auf aktuellen Daten basiert und nicht auf veralteten Audits. Automatisierte Erkennung deckt Anomalien in Echtzeit auf; Engineers entscheiden, was damit geschieht. Automatisierte Empfehlungen reduzieren die Diagnoselast; Engineers validieren und setzen um. Die Kombination führt zu schnelleren Reaktionszeiten als jeder Ansatz für sich allein.
Das Field-Data-Engineering-Team von DoiT unterstützt die Erkennungs- und Empfehlungsebene dieses Workflows, bettet Kostenmonitoring direkt in bestehende Pipelines ein und bereitet Befunde auf Job-Ebene mit genügend Kontext auf, um ohne zusätzliche Recherche handeln zu können. Diese Arbeit ist in das Google-Cloud-FinOps-Framework von DoiT integriert, sodass Kostenbefunde nicht in einem Dashboard darauf warten, dass jemand reinschaut.
Teams, die ihren aktuellen Stand vor der Automatisierung benchmarken möchten, finden im FinOps-KPI-Leitfaden von DoiT und in der Übersicht zu Cloud-Cost-Analytics-Tools nützliches Material, um Baselines zu setzen und die passende Instrumentierung auszuwählen.
BigQuery-Kostenoptimierung auf eine tragfähige Basis stellen
BigQuery-Kostenoptimierung im Jahr 2026 ist kein Projekt mit Abschlusstermin. Das Preismodell belohnt kontinuierliche Aufmerksamkeit: Slot-Baselines, die über die tatsächliche Nutzung hinausdriften, blähen die Rechnung leise auf; neue Tabellen ohne Partitionsrichtlinien sammeln über die Zeit Scankosten an; geplante Jobs für einen Anwendungsfall, der längst nicht mehr existiert, laufen weiter, weil niemand daran gedacht hat, sie abzuschalten. Die Kosten der Vernachlässigung wachsen schleichend und treten plötzlich zutage.
Teams, die BigQuery-Ausgaben unter Kontrolle halten, behandeln Optimierung als laufende Praxis, nicht als periodische Initiative. Sie haben Sichtbarkeit auf die Kostenzuordnung auf Job-Ebene. Sie reagieren auf Anomalien in dem Fenster, in dem sie noch adressierbar sind. Entscheidungen zu Partitionierung und Clustering treffen sie bei der Tabellenerstellung, nicht im Incident-Retro. Und sie haben einen Mechanismus, um Befunde in Maßnahmen umzusetzen, ohne einen separaten Backlog an Optimierungstickets aufzubauen, der mit der Feature-Arbeit konkurriert.
Die Field-Data-Engineering-Fähigkeiten von DoiT sind darauf ausgelegt, Erkenntnis und Umsetzung kontinuierlich zu verbinden – ohne den Overhead manueller Audits und ohne die Verzögerung nachgelagerter Rechnungen. Sprechen Sie mit einem DoiT Engineer über Partitionierung, Clustering, Slot-Tuning und kontinuierliches Kostenmonitoring über Ihren gesamten BigQuery-Footprint hinweg.
Häufig gestellte Fragen
Wann sollte ich von On-Demand auf BigQuery Editions wechseln?
Das klarste Signal ist ein konstanter Slot-Verbrauch oberhalb von 50 Slots. Bei 0,06 USD pro Slot-Stunde auf der Enterprise Edition kosten 100 Slots im Dauerbetrieb über einen Monat rund 4.380 USD – das entspricht grob einem Scan von 700 TiB On-Demand zu 6,25 USD pro TiB. Wenn Ihr monatliches Scanvolumen sich dieser Schwelle bei vorhersehbarem Timing nähert, spart Editions vermutlich Geld. Fragen Sie INFORMATION_SCHEMA.JOBS für die gesamten Slot-Millisekunden der letzten 30 bis 90 Tage ab, um Ihren tatsächlichen Break-even vor dem Commitment zu berechnen.
Was sind die drei BigQuery Editions, und worin unterscheiden sie sich?
Die Standard Edition eignet sich für Analytics-Teams mit moderaten, konstanten workloads. Sie unterstützt Autoscaling mit Pay-as-you-go-Pricing zu 0,04 USD pro Slot-Stunde (US-Region), bietet aber weder mehrjährige Commitments noch Idle-Slot-Sharing. Die Enterprise Edition ergänzt CMEK-Verschlüsselung, BI-Engine-Kapazität, Table Snapshots und Rabatte für 1- oder 3-jährige Commitments – die richtige Wahl für Produktions-workloads mit Sicherheits- oder Governance-Anforderungen. Enterprise Plus ergänzt regionsübergreifendes Disaster Recovery, Managed Backup und ein 99,999-%-SLA – ausgelegt für geschäftskritische Deployments, bei denen Ausfallzeiten regulatorische oder vertragliche Folgen haben.
Wie verhindere ich, dass eine einzelne Abfrage eine riesige BigQuery-Rechnung auslöst?
Setzen Sie den Parameter maximum_bytes_billed auf Query- oder Job-Ebene. Jede Abfrage, die mehr Bytes scannen würde als das konfigurierte Limit, scheitert sofort, statt durchzulaufen und die Gebühr zu erzeugen. Für On-Demand-Projekte wirkt diese Einstellung als harte Ausgabenobergrenze pro Abfrage. Für Editions-Projekte begrenzt sie den Slot-Verbrauch, indem sie das Scanvolumen deckelt, das die Abfragekomplexität treibt. Sie können diesen Parameter in der BigQuery-API, in der Konsole und in Client-Bibliotheken setzen und ihn als Organisationsrichtlinie über die Query-Settings-Kontrollen von Google Cloud durchsetzen.