Sizing a Single-Region Spanner Instance for 40K Reads and 7K Writes

The sizing rule that drives the decision For a single-region Spanner instance, the documented planning baseline for 1 KB rows is roughly 10,000 reads per second or 2,000 writes per second per node. The workload has two independent capacity dimensions that must both be satisfied: 40,000 reads/sec ÷ 10,000 reads/node = 4 nodes, and 7,000 writes/sec ÷ 2,000 writes/node = 3.5 nodes, which rounds up to 4 nodes. The larger requirement is four nodes, so option A is the smallest single-region configuration that handles the stated peak. Option C is clearly too small, option B overprovisions, and option D changes the availability architecture rather than minimizing capacity.

Why the six-node view is a trap The opposing six-node view appears to add extra headroom, but the stem asks for the most cost-effective size to handle the equivalent workload and gives the peak rates explicitly. Nothing in the scenario justifies rounding 3.5 write-nodes up to six; the correct rounding is to four. The community arithmetic that supports four nodes mirrors the documented baseline: satisfy the read ratio, satisfy the write ratio, and take the larger rounded-up result. Real Spanner throughput can vary with schema, hot spots, indexes, transaction mix, and CPU utilization, but those are post-migration tuning concerns unless the question adds them.

The adjacent decision: regional versus multi-region Option D is the availability decision, not the sizing decision. Multi-region Spanner is appropriate when the requirements demand cross-region disaster recovery, very high availability, or data residency, and it typically costs more and has different latency and node-capacity guidance. If the scenario changed to require 99.999% availability, cross-region failover, or a multi-region instance configuration, then D or a multi-region node count would become relevant. For a single-region equivalent workload with no such requirement, selecting multi-region is unnecessary spending.

What would flip the answer If the row size were substantially larger than 1 KB, if the workload had severe hot spots, if the stated 40,000 reads/sec and 7,000 writes/sec were sustained rather than peak, or if the operating policy required significant CPU headroom above the published baseline, more than four nodes could be justified. A requirement for automatic scaling during unpredictable spikes would also change the operational design. In that case, use Spanner monitoring to validate CPU and latency and adjust nodes or autoscaling rather than blindly doubling capacity.

Operational consequence of getting it wrong Four nodes is the cost-effective answer, but it should not be treated as a permanent set-and-forget guarantee. Underprovisioning causes high CPU utilization, increased latency, and transaction contention; overprovisioning such as six nodes wastes budget without a stated need. After migration, watch CPU utilization, latency, and hotspot metrics, and leave room for growth if production traffic approaches the planning ceiling.