Spanner Data Boost provides serverless compute for analytical queries and data exports, with the goal of isolating those workloads from transactional traffic. When you need to run a large report or move data into a warehouse, Data Boost lets you do that without competing for the same resources that handle your live customer transactions. For the Professional Cloud Database Engineer exam, the property to hold onto is that it keeps analytical work off the compute you have provisioned for the primary database.
Without Data Boost, an analytical query runs on the same instance as everything else. When the analytical workload starts, resource consumption on the transactional system spikes, because the query is fighting for the same CPU and memory as the transactional traffic. That contention can lead to latency for end users, and in the worst case it can lead to downtime. This is the situation Data Boost is designed to avoid.
Data Boost achieves near-zero impact on provisioned instance CPU resources by using independent capacity. The heavy lifting is offloaded to a separate pool of resources that Google Cloud manages, rather than tapping into the compute you have already provisioned for the database. The serverless compute nodes read data directly from Spanner's distributed storage layer, bypassing the transactional compute nodes entirely. That is why the transactional system stays relatively flat even after an analytical workload begins. The analytical processing shows up as separate capacity that scales up alongside it, not as a spike on the instance you are paying for.
It also scales elastically to handle burst loads without manual capacity planning or over-provisioning. If a query suddenly requires large throughput, the serverless layer expands to meet that demand automatically, and then shrinks back down once the job is finished. You do not size a fixed pool ahead of time for the peak.
This capability is useful for BigQuery federated queries. When BigQuery sends an external query to Spanner, it can leverage Data Boost to pull the data it needs. That lets you perform complex joins in BigQuery against live Spanner data without slowing down the production database that powers your applications. The federated query is issued through the EXTERNAL_QUERY function:
SELECT *
FROM EXTERNAL_QUERY('connection_id', 'query')One distinction worth carrying into the Professional Cloud Database Engineer exam is that federated queries are still a viable option for analytical tasks even when Data Boost is not mentioned. Federated querying from BigQuery into Spanner is the broader capability, and Data Boost is the serverless compute that makes it run without impacting transactional traffic. If a scenario describes reading live Spanner data from BigQuery and does not reference Data Boost by name, federated queries remain a correct way to do it.
Our Professional Cloud Database Engineer course covers Spanner Data Boost alongside BigQuery federated queries and workload isolation, with practice questions that drill these distinctions.
