BigQuery Goes Self-Tuning: 40% Slot Cuts and Per-Second Billing

Google is claiming up to a 40 percent reduction in BigQuery slot usage on standard benchmarks over 2025, alongside a 35 percent improvement in query performance across the same window. Those are engine-level gains delivered without customers rewriting a single line of SQL, and they land on top of a new self-learning optimiser that Google says will keep compounding those numbers into 2026. For a warehouse that bills by slot-seconds, a 40 percent efficiency delta is not a marketing figure. It is a direct line item on the invoice.

The Numbers

The headline claim, as IT Brief Australia reported, is that BigQuery delivered up to 35 percent better query performance during 2025 and cut processing costs, measured in slot usage, by as much as 40 percent on standard benchmarks. Google attributes those gains to three moving parts: the query processor, the execution engine, and the autoscaling model. The 2026 update layers a self-learning system, called history-based optimisations, on top of that baseline.

The per-customer data point Google chose to disclose is more interesting than the aggregate benchmark. One unnamed enterprise saw P90 execution time fall by up to 50 percent with slot usage down 15 percent and no regressions. Read that carefully. A 50 percent P90 improvement paired with only a 15 percent slot reduction implies the wins came from smarter execution plans, not from throwing less compute at the problem. The system got faster and cheaper at the same time, but the cost savings were the smaller half of the story for that workload.

The new advanced runtime pushes further, claiming up to 10x improvement on qualifying queries and up to 40 percent reduction in overall slot time. The short-query execution path claims up to 10x lower slot usage for small queries and P99 sub-second latency, with throughput up to 3x higher in some customer workloads. Fluid scaling, the per-second billing model for consumed slots, is pitched at an average cost reduction of up to 34 percent for autoscaling workloads.

The one named customer, ad-tech firm RISE, reports a 25 percent infrastructure cost reduction from fluid scaling alone, on a workload that processes more than 1 petabyte a day and 3 trillion monthly bids. That's the closest thing to a real-world reference point in the announcement, and it sits below Google's own "up to 34 percent" average. The source does not disclose what RISE's slot commit posture looked like before fluid scaling, which matters because per-second billing helps bursty workloads far more than steady-state ones. My rough bound: shops with autoscaling ratios above 3x peak-to-trough should expect savings in the RISE range, shops below 1.5x will see single-digit percentage improvements at best.

What's Actually New

Strip out the marketing and three things are genuinely different this cycle.

First, history-based optimisations. Traditional cost-based optimisers rely on static statistics gathered by ANALYZE-style operations, plus cardinality estimates that get progressively worse as joins deepen. Anyone who has debugged a Postgres plan flip on a table that grew 10x in a week knows the failure mode. BigQuery is now recording runtime statistics from earlier executions and feeding them back into planning for similar queries. Critically, Google says the system revokes any optimisation that fails to improve performance or causes a regression. That closed-loop behaviour is the part that matters. Adaptive query execution isn't new (Spark and Snowflake both have flavours of it), but a self-revoking optimiser with persistent memory across query executions is a step beyond adaptive-within-a-single-query.

Second, the short-query fast path. Cutting execution stages and reducing data shuffling to hit P99 sub-second latency is BigQuery admitting that dashboard and application workloads have been badly served by its distributed-first architecture. The 10x slot reduction claim on short queries is the tell: those queries were massively over-provisioned in the old execution model. Distributed shuffling for a query that touches 10,000 rows is pure overhead. This is BigQuery moving onto turf that ClickHouse and other OLAP engines have owned for high-concurrency serving.

Third, fluid scaling with per-second slot billing. BigQuery has always charged by slot-seconds in principle, but the autoscaler granularity mattered enormously for the effective bill. Moving to true per-second consumed-slot billing removes a rounding tax that hit spiky workloads hardest. This is the change that will show up on invoices fastest, with the least engineering effort required from customers.

The advanced runtime, with wider SIMD use and vectorised execution, is table stakes catch-up rather than novelty. Every serious analytical engine has been down this road. It matters for the aggregate 40 percent slot-time claim, but it isn't the differentiator.

What's Priced In for Data Teams

Most senior data platform leads have been expecting self-tuning behaviour to arrive at the warehouse layer. The economics were forcing it. When AI agents and automated pipelines generate orders of magnitude more queries than human analysts, manual index hints, materialised view management, and query rewrites don't scale. Databricks has been moving the same direction with predictive optimisation, and Snowflake has been layering more automation into its query acceleration service. So the direction is priced in.

What isn't priced in: the specific claim that history-based optimisations work without SQL changes or schema modifications, and revoke themselves on regression. If that holds in production on messy real workloads, it changes the operational profile of a BigQuery estate. Teams that currently employ dedicated performance engineers to review slow query dashboards will be able to reallocate that headcount. The DBA-adjacent roles at large BigQuery shops just got a harder question to answer about their next 24 months.

Also underestimated: the Iceberg angle. Google explicitly said the same optimisations, including filter pushdown, metadata-based pruning, page skipping, and asynchronous reads, apply to Apache Iceberg tables and BigQuery native storage. That is Google pricing the lakehouse defection scenario. If you can get warehouse-grade query optimisation over your Iceberg tables in object storage, the argument for keeping data locked in a proprietary format weakens. For teams already running dbt transformations on top of BigQuery, this makes format-agnostic modelling more viable without a performance penalty.

The unanswered question, and the one I would flag hardest for any CTO evaluating this: Google has not disclosed how history-based optimisations behave on query workloads with high semantic drift, where "similar" queries are hard to match. If the matching heuristic is conservative, the feature helps a narrow band of repetitive queries. If it's aggressive, false positives could produce regressions that the revocation system then has to catch. The source doesn't say how long the feedback loop takes to converge, which matters because that latency bounds the worst-case cost of a bad optimisation decision.

Contrarian View

The obvious read is that self-tuning warehouses commoditise data engineering skill and shift bargaining power back to the cloud provider. The contrarian read is the opposite: self-tuning makes cost forecasting harder, not easier.

Consider what fluid scaling plus history-based optimisations means for a finance team trying to budget. Compute holds resources for less time. Optimisations get applied and revoked based on runtime feedback the customer doesn't see. Slot consumption becomes a function of Google's internal decisions about which historical patterns to trust. The invoice goes down on average, but the variance around that average likely goes up. For workloads with strict cost-per-query SLAs (ad-tech real-time bidding, financial risk calcs, iGaming odds computation), variance matters more than average.

There is also a lock-in argument to consider. The more the engine tunes itself based on your specific query history, the more expensive it becomes to migrate. Your effective performance on BigQuery includes months of accumulated runtime statistics that don't port to another engine. That's a stickier moat than proprietary SQL dialects ever were.

My take: for shops running steady, well-understood workloads, the manual-tuning-is-dead framing overshoots. For shops running agent-driven or highly variable workloads, this changes the operating model in ways that will take a full budget cycle to fully appreciate. If Google's claims hold, we should see BigQuery net revenue retention among top-quartile customers accelerate over the next four quarters, and we should see at least one major public migration case study from Snowflake or Redshift to BigQuery citing these features specifically. If neither happens by Q3 2027, the practical impact was smaller than the announcement suggested.

Key Takeaways

• Google's 40 percent slot cost reduction claim over 2025 is the number that matters. On slot-seconds billing, engine efficiency flows straight to the invoice.
• History-based optimisations with automatic revocation is the genuinely new piece. Adaptive execution isn't novel, but persistent cross-query learning with self-rollback is a step past current Snowflake and Spark equivalents.
• The short-query fast path (10x lower slot usage, P99 sub-second) is BigQuery moving onto ClickHouse-style serving turf. High-concurrency dashboard workloads should retest cost economics.
• Fluid scaling per-second billing helps bursty workloads most. The RISE case shows 25 percent infrastructure cost reduction, below the 34 percent average, suggesting variance across workload shapes is high.
• Unanswered bound: Google hasn't disclosed how quickly history-based optimisations converge or how they handle semantic drift. If convergence takes weeks, the feature helps repetitive workloads far more than exploratory ones. Testable prediction: expect at least one large public migration case study citing these features by Q3 2027, or the practical impact was oversold.