GCP Spanner processing units cost: sizing below a full node

Quick answer

Cloud Spanner capacity is measured in processing units, where 1000 processing units equal one node, and you can provision in increments of 100 units below a node and in multiples of 1000 at or above a node. A regional node costs roughly 0.90 dollars per hour, about 650 dollars per month, so 100 processing units, one tenth of a node, cost around 65 dollars per month plus storage at about 0.30 dollars per GB per month. The fine-grained sizing means small workloads can run on 100 processing units instead of a full node, cutting the entry cost roughly tenfold, while larger workloads scale up in node-sized steps.

Cloud Spanner used to be sized only in whole nodes, which made its entry cost high for small workloads. Processing units changed that: they let you buy a fraction of a node, so a modest database no longer has to pay for a full node's capacity. Understanding the units, and how they map to nodes and storage, is the key to sizing Spanner without overpaying.

How processing units map to cost

Capacity	Equivalent	Approximate monthly cost (regional)
100 processing units	One tenth of a node	About 65 dollars
1000 processing units	One node	About 650 dollars
Storage	Per GB stored	About 0.30 dollars per GB

A regional node costs roughly 0.90 dollars per hour, near 650 dollars per month, and 1000 processing units equal that node. Below a node you provision in 100-unit increments, so 100 units cost about a tenth of a node, around 65 dollars per month. At or above one node you scale in whole-node steps of 1000 units. Storage is billed separately at about 0.30 dollars per GB per month, and multi-region configurations cost more per unit and per GB than regional ones.

Why fractional sizing matters

The 100-unit floor dramatically lowers the cost of getting started with Spanner. A small application that needs Spanner's global consistency but not a full node's throughput can run on 100 or a few hundred processing units, paying tens of dollars a month rather than the hundreds a full node would cost. This makes Spanner viable for smaller workloads that previously would have been priced out, without giving up its horizontal scalability as they grow.

Sizing to throughput and storage

Processing units determine throughput (queries and writes per second) and, up to a point, the storage each node's worth of units can back. Under-provisioning units starves throughput and raises latency, while over-provisioning pays for capacity you do not use. Google recommends keeping CPU utilization below a target so there is headroom for spikes, so size units to your steady load plus that headroom rather than to peak. Autoscaling can adjust processing units to demand, avoiding paying for peak capacity around the clock, similar to the approach for other managed databases.

Keeping Spanner cost efficient

Start small with 100 or a few hundred processing units for a new workload, measure CPU utilization and latency, and scale units up only as real load requires. Use autoscaling for variable traffic so you pay for peak capacity only when it is needed. Watch storage separately, since it grows independently of compute and is billed per GB. For steady large workloads, committed use discounts on Spanner reduce the per-unit rate. Price your Spanner configuration against the resource catalog so the processing units and storage are sized before you deploy.

FAQ

How is Cloud Spanner priced?

Spanner capacity is measured in processing units, where 1000 units equal one node. You provision in 100-unit increments below a node and in multiples of 1000 at or above a node. A regional node costs roughly 0.90 dollars per hour, about 650 dollars per month, so 100 processing units cost around 65 dollars per month, plus storage at about 0.30 dollars per GB per month billed separately.

What are Spanner processing units?

Processing units are the fine-grained measure of Spanner compute capacity, with 1000 units equal to one node. They let you provision a fraction of a node, as little as 100 units (one tenth of a node), so small workloads can run without paying for a full node. Units determine throughput and, up to a point, the storage they can back.

Why do processing units lower Spanner's entry cost?

Because the 100-unit floor lets a small workload run on one tenth of a node, roughly 65 dollars per month, instead of a full node at around 650 dollars. An application that needs Spanner's global consistency but not a full node's throughput can start at tens of dollars a month, making Spanner viable for smaller workloads that whole-node pricing would have priced out.

How do I size Spanner processing units?

Size to your steady load plus headroom rather than to peak, keeping CPU utilization below a target so there is room for spikes. Start small with 100 or a few hundred units for a new workload, measure utilization and latency, and scale up only as real load requires. Autoscaling can adjust units to demand so you pay for peak capacity only when needed.

How does C3X help with Spanner cost?

C3X prices your Spanner configuration from Terraform before you deploy, including processing units and storage, so the monthly cost of a given capacity is visible in the pull request. That lets you start with the smallest workable number of processing units and confirm the sizing before deploying, rather than provisioning a full node or over-sized capacity discovered on the bill.

What to do next

Size Spanner processing units before you deploy. C3X reads your Terraform and prices your resources against a live catalog. Start with the quickstart.