Google adds self-learning BigQuery tuning features

Google has added a set of autonomous query optimisation features to BigQuery, saying the changes have improved query performance and lowered processing costs.

The update centres on a self-learning system called history-based optimisations, which uses data from earlier query runs to decide whether to apply or avoid specific tuning changes in later executions. According to Google, the feature works without application rewrites, SQL changes or schema modifications, and revokes any optimisation that fails to improve performance or causes a regression.

The announcement reflects growing pressure on data platforms as companies run larger analytics estates and more AI-driven and automated workloads. Rather than relying on administrators to review execution plans, query hints and schema design manually, Google is positioning BigQuery to do more of that work inside the database engine.

Google said BigQuery delivered up to 35% better query performance during 2025 and cut query processing costs, measured in slot usage, by as much as 40% on standard benchmarks. It attributed those gains to changes in the query processor, execution engine and autoscaling model.

Self-learning engine

History-based optimisation is one of the main additions. Traditional query optimisers often rely on static statistics and estimates, which can become inaccurate in fast-changing datasets or complex joins across many tables. BigQuery records runtime statistics from earlier executions and uses them when similar queries appear again.

This allows the system to remember which changes improved a query and which did not. Google said it also uses those records to detect issues such as data skew and parameter-sensitive execution plans, where a small change in a filter can significantly affect performance.

One enterprise customer saw P90 execution times fall by up to 50%, while slot usage dropped by up to 15%, without regressions, according to Google. It did not identify the customer.

Runtime changes

Another part of the update is BigQuery advanced runtime, which changes how the engine executes workloads. Google said the software now makes broader use of vectorised execution and newer processor instruction sets, including SIMD, to reduce duplicate computation and process encoded data more directly.

Those changes can improve qualifying queries by up to 10 times and reduce overall slot time by as much as 40%, the company said. The gains depend on the type of query and the stage of execution where the methods can be applied.

Google also introduced a separate path for short queries, aimed at high-concurrency dashboard and application workloads that require low latency. By cutting the number of execution stages and reducing data shuffling, BigQuery is designed to handle these smaller requests with less distributed processing overhead.

That approach can reduce slot usage for short queries by up to 10 times and support P99 sub-second latency, according to Google. In some customer workloads, throughput rose by as much as three times because each query held compute resources for less time.

Open formats

Google said the same optimisation approach applies to open table formats, including Apache Iceberg, as well as BigQuery's native storage format. That matters for customers using lakehouse architectures and storing data in formats such as Parquet while still running analysis through BigQuery.

Features including filter pushdown, metadata-based pruning, page skipping and asynchronous reads are available across those storage choices, Google said. It argued that customers should not have to trade performance for flexibility in data format.

Cost model

The latest changes also include what Google calls fluid scaling in the BigQuery autoscaler. Because BigQuery charges compute by slot-seconds rather than fixed clusters or node allocations, efficiency gains can translate directly into lower spending, Google said.

Fluid scaling brings per-second billing for consumed slots and lowers costs by an average of up to 34% for autoscaling workloads, according to Google. The company presented it as part of a broader effort to reduce total cost of ownership for analytics users with variable demand.

One customer Google cited was RISE, an advertising technology company that processes more than 1 petabyte of data a day and manages more than 3 trillion monthly bids, according to the cloud provider.

"In the high-stakes world of advertising, every cent counts. BigQuery's Fluid Scaling has reduced our infrastructure cost by 25% allowing us to scale our slot consumption and accelerate our entire workflow. By delivering faster model results and increasing our hourly data processing throughput, we're providing our customers with the 'freshest' data possible," said Chen Shalit, Chief Executive Officer and Co-Founder of RISE.

AI workloads

The changes come as cloud providers adapt analytics products for AI agents and application-driven querying, where machines generate far more requests than human analysts. Google said those workloads place heavier demands on latency and concurrency, making manual tuning less practical.

For BigQuery, that means moving further from a conventional data warehouse model towards a self-tuning query engine that can handle changing query shapes, data growth and fluctuating compute demand with less intervention from database teams.

Google said its goal is for users to see better performance without changing code or managing infrastructure by hand, as agent and human workloads run on the same platform.