How to Optimize Cloud Spanner Costs With Granular Instances

To optimize Cloud Spanner costs with granular instances, switch from node-based to processing-unit sizing, right-size to the smallest multiple of 100 PU that keeps CPU under the recommended threshold, enable the managed autoscaler so capacity tracks load, then buy a committed use discount on the steady floor. One node equals 1,000 PU, and a 100-PU regional instance starts around 65 US dollars per month, so granular sizing can cut a small Spanner bill by up to 90 percent versus a full node. The order matters: rightsize and autoscale before you commit.

Last updated: June 2026. Written by Morten Andersen and reviewed by Fredrik Filipsson, built on our See, Cut, Lock, Run method.

This article sits in our complete guide to Google Cloud cost optimization, the cluster pillar it links up to, and is part of the broader cloud cost optimization playbook. Rightsizing Spanner capacity is a Cut step move. For the choice between Spanner and other managed databases, see our companion Cloud SQL vs AlloyDB cost and performance comparison.

What is a granular Spanner instance?

A granular Spanner instance is one sized in processing units instead of whole nodes. One Spanner node equals 1,000 processing units, and granular sizing lets you provision compute capacity in steps of 100 PU, from a minimum of 100 PU up to 1,000 PU, all with zero downtime, per the Spanner compute capacity documentation. That granularity is what makes Spanner affordable for smaller workloads: instead of paying for a full node when you need a tenth of one, you pay for the 100-PU or 200-PU step that matches your load. When you set or change capacity, processing units must be specified in multiples of 100.

How much does granular Spanner capacity cost?

A 100-PU regional Spanner instance costs on the order of 65 US dollars per month for compute, before storage and network, and a three-year committed use discount of roughly 40 percent can bring that floor below 40 US dollars per month, per the Spanner pricing documentation. Because capacity scales in 100-PU steps, the cost scales linearly: 200 PU is about double the 100-PU rate, and so on up to a full node. Storage and network are billed separately and are unaffected by the compute granularity. Verify the current per-100-PU rate for your region in that documentation before modeling, because Spanner pricing changes.

How do you right-size and autoscale a Spanner instance?

Right-size by measuring utilization, then provision the smallest 100-PU step that holds CPU under the recommended threshold, and autoscale where load varies. The steps below are the Cut-then-Lock sequence from our method.

1. Measure utilization. Check CPU utilization and storage against your current node or PU capacity in Cloud Monitoring to see how much headroom you are paying for.
2. Switch to processing units. Move from node-based sizing to processing units so you can provision in steps of 100 instead of whole 1,000-PU nodes.
3. Right-size to the 100-PU step you need. Set compute capacity to the smallest multiple of 100 PU that keeps CPU below the recommended threshold with headroom for spikes.
4. Enable the managed autoscaler. On Enterprise or Enterprise Plus editions, turn on the managed autoscaler with a minimum and maximum PU range so capacity tracks load instead of sitting at peak, per the managed autoscaler documentation.
5. Apply a committed use discount. Once the steady floor is clear, buy a one-year or three-year Spanner committed use discount on that baseline to cut the rate further.

When should you use the managed autoscaler?

Use the managed autoscaler when Spanner load varies through the day or week, and a fixed size when it is flat. The autoscaler, available on Enterprise and Enterprise Plus editions, adjusts processing units automatically within a range you set, so a workload that peaks during business hours scales down overnight instead of holding peak capacity around the clock. That converts idle headroom into savings without a custom scaling job. For genuinely flat, predictable load, skip the autoscaler: a fixed granular size plus a committed use discount on the whole baseline is simpler and cheaper, because there is no variability to chase.

What mistakes inflate a Spanner bill?

The biggest Spanner cost mistakes are running whole nodes at low utilization, holding peak capacity off-peak, and committing before rightsizing. Many estates still run a full 1,000-PU node out of habit when CPU sits in the low double digits, paying for capacity they will never use. Others provision for the daily peak and never scale down, when the managed autoscaler would release that capacity automatically. And some buy a committed use discount on an oversized instance, locking the waste in for the full term. The fix is the sequence in this guide: measure, move to processing units, rightsize to the 100-PU step, autoscale, then commit. The full Spanner and database playbook lives in our Google Cloud guide.

Frequently asked questions

What is a granular Spanner instance?

A granular Spanner instance is one sized in processing units rather than whole nodes. One node equals 1,000 processing units, and granular sizing lets you provision in steps of 100 PU, from 100 PU up to 1,000 PU, so small and mid-size workloads pay for a fraction of a node instead of a whole one.

How much does 100 processing units of Spanner cost?

A 100-PU regional Spanner instance is on the order of 65 US dollars per month for compute, before storage and network. With a three-year committed use discount of about 40 percent, that floor can drop below 40 US dollars per month. Confirm the current rate for your region in the Spanner pricing documentation, because prices change.

Should I use the Spanner managed autoscaler?

Use the managed autoscaler when load varies through the day or week, so capacity scales down off-peak instead of holding at peak. It is available on the Enterprise and Enterprise Plus editions and removes the need to run a custom autoscaler. For flat, predictable load, a fixed granular size plus a committed use discount is simpler and cheaper.

Do processing units have to be multiples of 100?

Yes. When you set or change Spanner compute capacity, processing units must be specified in multiples of 100, for example 100, 200, or 300, up to 1,000 PU per node. Above 1,000 PU, capacity is added in whole-node increments of 1,000 PU.

The short version

Granular Spanner sizing lets you provision in 100-PU steps instead of whole nodes, so a small workload pays around 65 US dollars per month rather than a full node's price. Measure, move to processing units, rightsize, autoscale, then commit. When you want that sequence run on your instances, that is what our Google Cloud cost optimization service delivers.