Spanner and Bigtable cost optimization is mostly about provisioned capacity, because both databases charge for the compute you allocate whether or not you use it, plus storage and network on top. Spanner is the globally distributed relational database billed by nodes or processing units; Bigtable is the wide-column NoSQL store billed by nodes per cluster. In both, the dominant cost is compute capacity that runs continuously, so the central question is whether that capacity matches real demand or sits provisioned for a peak that rarely comes. Get capacity right, let it scale, and commit the steady part, and the bill follows.
This article is part of our Google Cloud cost optimization cluster. For the full picture, start with the complete guide to Google Cloud cost optimization, the pillar this piece links up to. The same provisioned-capacity discipline applies to managed relational databases, covered in Cloud SQL cost optimization.
Size to real load, not to the peak
The most common waste in both databases is capacity provisioned for a worst-case peak and left there permanently. Watch the utilization signals each service exposes, such as CPU and storage pressure, and size the node or processing-unit count so the instance runs comfortably at typical load with headroom for spikes, not so it idles at a fraction of capacity all day. Spanner's processing-unit granularity lets smaller workloads run below a full node, which avoids paying for a whole node when a fraction will do. The goal is an instance that is busy enough to justify its size most of the time.
Let capacity autoscale with demand
Both services can adjust capacity to load rather than holding a fixed allocation, which matters most for workloads with a clear daily or weekly cycle. Spanner offers managed autoscaling that adds and removes processing units as utilization moves, and Bigtable supports autoscaling of node counts within a cluster. Enable it so the database shrinks during quiet hours and grows for busy ones, instead of paying for the peak continuously. As with any database, set a sensible minimum so latency stays healthy and the autoscaler does not thrash, but the saving from not funding the peak overnight is usually substantial.
Paying for database capacity you use only at peak?
Our cost audit profiles your Spanner and Bigtable load, right-sizes the capacity, turns on autoscaling, and commits the steady base so you stop funding the peak around the clock. On the performance model, you pay only from realized savings. No savings, no fee.
Book a GCP cost audit →Manage storage and unused data
Beyond compute, both databases charge for stored data, and storage grows quietly as tables accumulate history nobody reads. Use time-to-live or expiry policies to age out data that no longer needs to live in an expensive operational store, and move cold history to cheaper storage when the access pattern allows, the same lifecycle thinking covered in Google Cloud storage classes and lifecycle management. In Bigtable, schema and key design also affect how much capacity a workload needs, so a hot-spotted key pattern can force more nodes than the data volume would suggest. Fixing the access pattern can lower the node count directly.
Commit the steady base
Once capacity is sized and scaling, the part of the load that never goes away is a candidate for a committed-use discount. Committing the steady floor of Spanner or Bigtable capacity for a one or three year term trades flexibility you do not need on that base for a meaningful rate reduction, while autoscaling handles the variable layer above it on demand. This is the standard pattern: commit the baseline, flex the peak. Reservations should come last, on a clean baseline you have already right-sized, which is the same sequence our method applies across every service.
| Lever | Spanner | Bigtable |
|---|---|---|
| Capacity unit | Nodes or processing units | Nodes per cluster |
| Right-sizing | To utilization signals | To CPU and key design |
| Autoscaling | Managed autoscaler | Node autoscaling |
| Storage control | Expiry and archiving | TTL and garbage collection |
| Commitment | Committed use on base | Committed use on base |
Capacity models, autoscaling and committed-use options above reflect Google Cloud as of May 2026. Verify the current Spanner and Bigtable pricing, processing-unit granularity and discount terms in Google Cloud documentation before changing production capacity, as they evolve.
The Google Cloud Cost Optimization Field Guide includes the database capacity-sizing worksheet behind this article. It is the downloadable companion.
The short version
Spanner and Bigtable cost is provisioned capacity. Size each instance to real load rather than the daily peak, turn on autoscaling so capacity falls in quiet hours, control storage with expiry and good key design, and commit the steady base for a discount while flexing the peak on demand. When you want your databases profiled and these levers applied for you, that is what our Google Cloud cost optimization service delivers.