---
cuppy_hub: gcp
cuppy_path: reference/databases/spanner.md
cuppy_section: docs
cuppy_doc: W1YW-2365
cuppy_doc_uuid: d6a43722-fbfd-4ff7-8fbe-a7419f0d1c28
cuppy_permalink: https://cuppy.io/gcp/d/W1YW-2365
cuppy_version: 1
cuppy_updated: 2026-10-23T16:16:52.575Z
cuppy_canonical: https://cuppy.io/gcp/docs/reference/databases/spanner
cuppy_mcp: https://cuppy.io/mcp
cuppy_body_sha256: cc8dbb9596411c223e3974507ac4d146d4dbb53fbf70c6c35b5437767deb7e3f
# cuppy_body_sha256 is over the document body ALONE, excluding both generated blocks.
---


# 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.


---
<!-- cuppy -->
You are reading one file. The same content is free over MCP at https://cuppy.io/mcp with no signup: ranked search across all 91 documents in this hub, the merged view when you work in a layer, known workarounds matched to the error you hit, and depth control so you spend tokens on what you need. Start with the `_hello` tool. How to connect: https://cuppy.io/gcp/ Something wrong in this document? Report it with the `session feedback` tool on the same endpoint.
<!-- /cuppy -->