Spanner — the three instance configurations, their stated availability, and the write-latency trade they encode
Horizontally scaling relational storage. The regional, dual-region and multi-region configurations with the availability figures the vendor states and what each does to write latency, which configurations need Enterprise Plus, and the capacity units.
markdownreferencev1W1YW-2365stage: designtrust: officialfamily: databasesservice: spannerinterface: anyspannerinstance configurationregionaldual-regionmulti-region99.99%99.999%read-write replicawitness replicaread-only replicanodesprocessing unitsEnterprise Plus
Spanner instance configurations
1. The three configurations
| Configuration | Shape | Stated availability | Write latency | Writes from |
|---|---|---|---|---|
| regional | one region, three read-write replicas in different zones | 99.99% | lowest | one location |
| dual-region (Enterprise Plus only) | two regions in a single country, six replicas (three per region) | 99.999% | slightly higher | two areas can read |
| multi-region (Enterprise Plus only) | multiple regions: two read-write regions, plus witness and read-only replicas | 99.999% | highest | multiple locations |
2. What the table actually encodes
One trade, stated three ways: more geographic spread buys an availability nine and costs write latency. Because a Spanner write must reach a quorum of replicas, and the replicas are further apart.
Read it as a design rule:
- regional is the default. Three zones, 99.99%, and the lowest write latency available.
- dual-region buys the fifth nine while staying inside one country — which is usually a data-residency
requirement as much as an availability one.
- multi-region is the only one that accepts writes in more than one place, and it is the most expensive
in latency. Choose it for a genuinely globally-distributed write workload, not for read locality: read-only replicas serve that.
Two of the three need Enterprise Plus. So "we will start regional and go multi-region later" is an edition change as well as a configuration change.
3. Capacity units
Capacity is expressed in nodes and processing units. Recorded as an absence: this page states no minimum for either, so none is written here. Read the current minimum and the node-to-processing-unit relationship from the compute-capacity page before sizing.
4. Where Spanner is the right answer, and where it is not
| choose Spanner when | one primary cannot take the writes, or the availability requirement is above what a single region gives, or writes must be accepted in more than one geography |
| do not choose it when | a single regional primary is enough — Cloud SQL or AlloyDB will be simpler and the application will need no changes (reference/databases/cloud-sql.md, reference/databases/alloydb.md) |
The comparison that matters for a migration: Cloud SQL's HA is a standby VM in another zone within one region. Spanner's baseline is three read-write replicas across zones with a stated 99.99%. These are different availability models, not different tiers of the same one, and moving between them is an application change.
5. For a cross-cloud estimate
Spanner's closest counterparts are AWS Aurora (and Aurora DSQL) and Azure Cosmos DB — Google's own table pairs Spanner with Azure Cosmos DB for NoSQL and with Azure Database for PostgreSQL, which is already a sign that no single counterpart is right. The honest statement, and the one to put in an estimate:
Spanner's combination of relational semantics with horizontal write scaling and a published multi-region write capability does not have a like-for-like counterpart on either other cloud. Treat a move off Spanner as an architecture change, and a move onto it as a possible simplification of an application that is currently sharding manually.
See guides/parity/databases.md §3.