BigQuery wird selbstoptimierend: 40 % weniger Slots und sekundenbasierte Abrechnung

Google behauptet, dass der BigQuery-Slot-Verbrauch auf Standard-Benchmarks im Jahr 2025 um bis zu 40 Prozent gesunken ist – bei gleichzeitig 35 Prozent besserer Abfrageleistung im gleichen Zeitraum. Diese Gewinne sind auf Engine-Ebene entstanden, ohne dass Kunden eine einzige SQL-Zeile anpassen mussten. Hinzu kommt ein neuer selbstlernender Optimierer, der diese Verbesserungen laut Google auch 2026 weiter steigern soll. Für ein Warehouse, das nach Slot-Sekunden abrechnet, ist ein Effizienzgewinn von 40 Prozent kein Marketingwert – er erscheint direkt auf der Rechnung.

Die Zahlen

Die Kernaussage, über die IT Brief Australia berichtete, lautet: BigQuery lieferte 2025 bis zu 35 Prozent bessere Abfrageleistung und senkte die Verarbeitungskosten gemessen am Slot-Verbrauch auf Standard-Benchmarks um bis zu 40 Prozent. Google führt diese Gewinne auf drei Komponenten zurück: den Abfrageprozessor, die Ausführungs-Engine und das Autoscaling-Modell. Das 2026er-Update legt ein selbstlernendes System namens „History-based Optimisations" über diese Basis.

Interessanter als der aggregierte Benchmark ist der einzelne Kundendatenpunkt, den Google offengelegt hat. Ein nicht genanntes Unternehmen verzeichnete einen Rückgang der P90-Ausführungszeit um bis zu 50 Prozent bei gleichzeitig 15 Prozent weniger Slot-Verbrauch und keinerlei Regressionen. Das verdient genaue Betrachtung: Eine 50-prozentige P90-Verbesserung bei nur 15 Prozent weniger Slots deutet darauf hin, dass die Gewinne aus intelligenteren Ausführungsplänen stammen – nicht daraus, weniger Rechenleistung einzusetzen. Das System wurde gleichzeitig schneller und günstiger, wobei die Kosteneinsparungen für diese Arbeitslast der kleinere Teil der Geschichte waren.

Die neue Advanced Runtime geht noch weiter und beansprucht bis zu 10-fache Verbesserung bei qualifizierenden Abfragen sowie bis zu 40 Prozent Reduktion der gesamten Slot-Zeit. Der Schnellpfad für kurze Abfragen verspricht bis zu 10-fach niedrigeren Slot-Verbrauch für kleine Abfragen, P99-Latenz unter einer Sekunde und bei einigen Kunden-Workloads bis zu 3-fach höheren Durchsatz. Fluid Scaling, das sekundenbasierte Abrechnungsmodell für verbrauchte Slots, wird mit einer durchschnittlichen Kostensenkung von bis zu 34 Prozent für Autoscaling-Workloads angepriesen.

Der einzige namentlich genannte Kunde, das Ad-Tech-Unternehmen RISE, berichtet von einer 25-prozentigen Infrastrukturkostensenkung allein durch Fluid Scaling – bei einem Workload, der täglich mehr als 1 Petabyte verarbeitet und monatlich 3 Billionen Gebote abwickelt. Das ist der nächste Anhaltspunkt an einer realen Referenz in der Ankündigung, liegt aber unterhalb von Googles eigenem Durchschnittswert von „bis zu 34 Prozent". Die Quelle gibt nicht preis, wie RISE vorher mit Slot-Commitments aufgestellt war, was relevant ist, da sekundengenaue Abrechnung ungleichmäßigen Workloads deutlich mehr nützt als gleichmäßigen. Meine grobe Einschätzung: Betriebe mit Autoscaling-Verhältnissen über 3x Peak-zu-Trough sollten Einsparungen im RISE-Bereich erwarten, Betriebe unter 1,5x werden bestenfalls einstellige Prozentverbesserungen sehen.

Was wirklich neu ist

Lässt man das Marketing beiseite, sind in diesem Zyklus drei Dinge wirklich anders.

Erstens: History-based Optimisations. Traditionelle kostenbasierte Optimierer stützen sich auf statische Statistiken aus ANALYZE-ähnlichen Operationen sowie auf Kardinalitätsschätzungen, die mit tieferen Joins zunehmend ungenauer werden. Wer schon einmal einen Postgres-Plan-Flip auf einer Tabelle debuggt hat, die in einer Woche um das 10-fache gewachsen ist, kennt das Fehlermuster. BigQuery zeichnet nun Laufzeitstatistiken aus früheren Ausführungen auf und speist diese bei ähnlichen Abfragen in die Planung ein. Entscheidend: Google zufolge widerruft das System jede Optimierung, die die Leistung nicht verbessert oder eine Regression verursacht. Dieses Closed-Loop-Verhalten ist der entscheidende Teil. Adaptive Abfrageausführung ist nicht neu (Spark und Snowflake haben beide entsprechende Varianten), aber ein selbstwiderrufender Optimierer mit persistentem Gedächtnis über Abfrageausführungen hinweg ist ein Schritt über die adaptive Ausführung innerhalb einer einzelnen Abfrage hinaus.

Zweitens: der Schnellpfad für kurze Abfragen. Weniger Ausführungsstufen und reduziertes Data Shuffling für P99-Latenz unter einer Sekunde ist Googles Eingeständnis, dass Dashboard- und Anwendungs-Workloads von der verteilungsorientierten Architektur von BigQuery schlecht bedient wurden. Der Anspruch der 10-fachen Slot-Reduktion bei kurzen Abfragen ist aufschlussreich: Diese Abfragen waren im alten Ausführungsmodell massiv überprovisioniert. Verteiltes Shuffling für eine Abfrage, die 10.000 Zeilen berührt, ist reiner Overhead. Damit betritt BigQuery Terrain, das ClickHouse und andere OLAP-Engines bisher für hochparallelisiertes Serving besetzt hielten.

Drittens: Fluid Scaling mit sekundenbasierter Slot-Abrechnung. BigQuery hat im Prinzip schon immer nach Slot-Sekunden abgerechnet, aber die Granularität des Autoscalers hatte enormen Einfluss auf die effektive Rechnung. Der Wechsel zur echten sekundengenauen Abrechnung für verbrauchte Slots beseitigt eine Rundungssteuer, die ungleichmäßige Workloads am härtesten traf. Diese Änderung wird am schnellsten auf Rechnungen sichtbar und erfordert am wenigsten technischen Aufwand seitens der Kunden.

Die Advanced Runtime mit erweiterter SIMD-Nutzung und vektorisierter Ausführung ist eher ein Aufholspiel als eine Neuerung. Jede ernsthafte Analyse-Engine hat diesen Weg bereits beschritten. Sie trägt zur aggregierten 40-Prozent-Slot-Zeit-Reduzierung bei, ist aber kein Alleinstellungsmerkmal.

Was Data-Teams bereits einkalkuliert haben

Die meisten erfahrenen Data-Platform-Verantwortlichen haben damit gerechnet, dass selbstoptimierendes Verhalten auf der Warehouse-Ebene ankommt. Die Wirtschaftlichkeit hat es erzwungen. Wenn KI-Agenten und automatisierte Pipelines um Größenordnungen mehr Abfragen erzeugen als menschliche Analysten, lassen sich manuelle Index-Hints, Verwaltung von Materialized Views und Abfrage-Rewrites nicht mehr skalieren. Databricks bewegt sich mit Predictive Optimisation in dieselbe Richtung, und Snowflake schichtet mehr Automatisierung in seinen Query Acceleration Service. Die Richtung ist also eingepreist.

Was noch nicht eingepreist ist: die spezifische Aussage, dass History-based Optimisations ohne SQL-Änderungen oder Schema-Modifikationen funktionieren und sich bei Regressionen selbst zurücksetzen. Wenn das bei echten, unordentlichen Produktions-Workloads Bestand hat, verändert es das Betriebsprofil eines BigQuery-Bestands. Teams, die derzeit dedizierte Performance-Engineers für die Überprüfung von Slow-Query-Dashboards einsetzen, könnten diese Kapazitäten umschichten. Die DBA-nahen Rollen in großen BigQuery-Umgebungen stehen vor einer schwierigeren Frage bezüglich ihrer nächsten 24 Monate.

Ebenfalls unterschätzt: der Iceberg-Aspekt. Google erklärte ausdrücklich, dass dieselben Optimierungen – einschließlich Filter Pushdown, metadatenbasiertem Pruning, Page Skipping und asynchronem Lesen – auf Apache Iceberg-Tabellen und BigQuery's nativen Speicher angewendet werden. Das ist Googles Antwort auf das Lakehouse-Abwanderungsszenario. Wenn man Warehouse-taugliche Abfrageoptimierung über Iceberg-Tabellen in Object Storage bekommt, schwächt das das Argument, Daten in einem proprietären Format zu halten. Für Teams, die bereits dbt-Transformationen auf BigQuery betreiben, macht dies formatagnostisches Modellieren ohne Leistungseinbußen praktikabler.

Die unbeantwortete Frage – und die, die ich jedem CTO bei der Evaluierung am stärksten ans Herz legen würde: Google hat nicht offengelegt, wie History-based Optimisations bei Abfrage-Workloads mit hohem semantischen Drift reagieren, bei denen „ähnliche" Abfragen schwer zu matchen sind. Ist das Matching-Heuristik konservativ, hilft das Feature nur einer schmalen Bandbreite repetitiver Abfragen. Ist es aggressiv, könnten False Positives Regressionen erzeugen, die das Revocation-System dann auffangen muss. Die Quelle gibt nicht an, wie lange die Feedback-Schleife zur Konvergenz braucht – das ist relevant, weil diese Latenz die Worst-Case-Kosten einer schlechten Optimierungsentscheidung begrenzt.

Eine andere Sichtweise

Die naheliegende Lesart ist, dass selbstoptimierende Warehouses Data-Engineering-Expertise zur Massenware machen und die Verhandlungsmacht zum Cloud-Anbieter zurückverlagern. Die Gegenthese lautet das Gegenteil: Selbstoptimierung macht Kostenprognosen schwieriger, nicht einfacher.

Man bedenke, was Fluid Scaling plus History-based Optimisations für ein Finance-Team bedeutet, das ein Budget aufstellen muss. Compute hält Ressourcen kürzer. Optimierungen werden basierend auf Laufzeit-Feedback angewendet und widerrufen, das der Kunde nicht einsehen kann. Der Slot-Verbrauch wird zur Funktion interner Google-Entscheidungen darüber, welchen historischen Mustern vertraut wird. Die Rechnung sinkt im Durchschnitt, aber die Varianz um diesen Durchschnitt steigt wahrscheinlich. Für Workloads mit strengen Cost-per-Query-SLAs (Ad-Tech Real-Time Bidding, Finanzrisikoberechnungen, iGaming-Quotenberechnung) ist Varianz wichtiger als der Durchschnitt.

Auch ein Lock-in-Argument ist zu berücksichtigen. Je mehr die Engine sich auf Basis der eigenen spezifischen Abfragehistorie selbst optimiert, desto teurer wird eine Migration. Die effektive Leistung auf BigQuery beinhaltet monatelang angesammelte Laufzeitstatistiken, die sich nicht auf eine andere Engine übertragen lassen. Das ist ein zäherer Burggraben als proprietäre SQL-Dialekte es je waren.

Meine Einschätzung: Für Betriebe mit stabilen, gut verstandenen Workloads schießt die Aussage „manuelle Optimierung ist tot" übers Ziel hinaus. Für Betriebe mit agentengesteuerten oder hochvariablen Workloads verändert dies das Betriebsmodell in einer Weise, die einen vollständigen Budgetzyklus braucht, um vollständig erfasst zu werden. Wenn Googles Aussagen halten, sollten wir sehen, dass die BigQuery-Nettoumsatzbindung unter den Top-Quartil-Kunden in den nächsten vier Quartalen zunimmt, und wir sollten mindestens eine große öffentliche Migrations-Fallstudie von Snowflake oder Redshift zu BigQuery sehen, die genau diese Features zitiert. Tritt beides bis Q3 2027 nicht ein, war die praktische Wirkung geringer als die Ankündigung vermuten ließ.

Wichtigste Erkenntnisse

• Googles Behauptung einer 40-prozentigen Slot-Kostensenkung über 2025 ist die entscheidende Zahl. Bei Slot-Sekunden-Abrechnung schlägt Engine-Effizienz direkt auf die Rechnung durch.
• History-based Optimisations mit automatischem Widerruf ist das wirklich Neue. Adaptive Ausführung ist nicht neu, aber persistentes Query-übergreifendes Lernen mit Self-Rollback geht über aktuelle Snowflake- und Spark-Äquivalente hinaus.
• Der Schnellpfad für kurze Abfragen (10-fach niedrigerer Slot-Verbrauch, P99 unter einer Sekunde) ist BigQuerys Vorstoß auf das ClickHouse-Terrain für hochparallelisiertes Serving. Dashboard-Workloads mit hoher Parallelität sollten die Kostenökonomie neu bewerten.
• Fluid Scaling mit sekundenbasierter Abrechnung hilft ungleichmäßigen Workloads am meisten. Der RISE-Fall zeigt 25 Prozent Infrastrukturkostensenkung, unterhalb des Durchschnittswerts von 34 Prozent – was auf hohe Varianz je nach Workload-Typ hindeutet.
• Offene Frage: Google hat nicht offengelegt, wie schnell History-based Optimisations konvergieren oder wie sie mit semantischem Drift umgehen. Dauert die Konvergenz Wochen, hilft das Feature repetitiven Workloads weit mehr als explorativen. Überprüfbare Prognose: Mindestens eine große öffentliche Migrations-Fallstudie, die diese Features zitiert, bis Q3 2027 – andernfalls wurde die praktische Wirkung übertrieben dargestellt.