Resource allocation in Cloud Spanner comes down to how much compute capacity you provision and how that capacity maps to throughput. Compute capacity is expressed in nodes or in processing units, and the amount you assign determines both the read and write operations the instance can serve and the total storage it can hold. The Professional Cloud Database Engineer exam tends to test whether you can size an instance from a stated throughput requirement and whether you know when to scale compute versus address storage directly, so it helps to work through the numbers rather than memorize a single figure.
When we talk about throughput in Spanner, we are measuring the operations per second that a single node can handle. As of the figures used here, a single node serves roughly 10,000 read operations per second. For writes, specifically writing single 1KB rows, a single node provides about 2,000 operations per second. That ratio matters when you size an instance, because reads and writes draw on the same capacity but at very different rates, and the workload that dominates is the one that sets your node count.
Working an example makes the logic concrete. Suppose you need to support 35,000 reads per second and 5,000 writes per second. Dividing 5,000 writes by the 2,000 write capacity gives 2.5 nodes for the write side. Dividing 35,000 reads by the 10,000 read capacity gives 3.5 nodes for the read side. You have to satisfy the higher of the two requirements and round up to a whole number, so you would provision 4 nodes.
Now raise the target to 40,000 reads and 11,000 writes per second. For reads, 40,000 divided by 10,000 is exactly 4 nodes. For writes, 11,000 divided by 2,000 is 5.5 nodes. The write requirement is higher, so you round up and provision 6 nodes to fully support the write throughput. This same pattern, compute each side independently, take the larger, then round up, is the calculation to keep in mind if the exam asks you to determine a node count from throughput requirements.
Raw per-node capacity tells you what an instance can do in theory, but in production you use Cloud Monitoring to track how the instance is actually holding up under real load. To monitor Spanner's performance you need at least the monitoring.viewer role.
There are recommended CPU thresholds, and they differ between single-region and multi-region instances. For single-region instances, high-priority CPU usage should stay at or below 65 percent, and the 24-hour smoothed aggregate CPU usage should stay under 90 percent. For multi-region instances, high-priority CPU usage should stay at or below 45 percent, while the 24-hour smoothed aggregate CPU usage should again be under 90 percent. The lower high-priority threshold for multi-region instances is worth remembering, since it is an easy detail to confuse. When usage exceeds these thresholds, it is a sign the instance may be under-provisioned, and the appropriate response is to add nodes so the instance can handle the increased workload while maintaining availability and consistency.
Monitoring often reveals that performance is not your only constraint. Storage utilization can approach its recommended limits as well, and there are two main ways to bring it down.
The first is to add compute capacity. Adding nodes raises the total storage ceiling of the instance, and this is a fast operation, typically taking anywhere from a few minutes to an hour to take effect. The second is to delete data. Deleting data reduces the amount stored, but compacting that storage and reflecting it in your metrics is much slower, often taking anywhere from 12 hours to a week.
The general recommendation is to scale compute capacity first to give yourself breathing room, then diagnose and resolve the sources of the high storage usage. Because adding capacity acts quickly and deleting data does not, scaling up is the way to relieve immediate pressure, and the cleanup of the underlying data can follow once the instance is no longer near its limit.
You can manage compute capacity manually, but Spanner also offers autoscaling, which automatically adds or removes compute capacity based on the real-time needs of the application. This is a horizontal scaling model, because the system scales by adjusting the number of separate nodes or processing units rather than by changing the size of a single machine.
Autoscaling provides a few benefits. It reduces costs, because you are not paying for idle resources during low-traffic periods. It minimizes management overhead, since the team does not have to monitor metrics and trigger scaling events by hand. And it maintains performance by keeping compute resources available to meet sudden spikes in demand without manual intervention.
Two situations are the best fit for autoscaling. The first is periodic traffic patterns, such as an application that is busy during the day and quiet at night, where capacity can rise and fall with predictable demand. The second is new applications or workloads, where you do not yet have enough historical data to predict how much capacity you will need. In both cases, letting the autoscaler adjust capacity is more reliable than guessing at a fixed size. For the Professional Cloud Database Engineer exam, it is enough to recognize these as the scenarios where autoscaling is the recommended approach and to remember that it works by changing the number of nodes or processing units.
Our Professional Cloud Database Engineer course covers Cloud Spanner resource allocation alongside instance configurations and monitoring, with practice questions that drill these distinctions.
