This page describes the different types of instance configurations available inSpanner, and the differences and trade-offs between them.

Instance configurations

A Spanner instance configuration defines the geographic placementand replication of the databases in that instance. When you create an instance,you must configure it as eitherregional,dual-region, ormulti-region.You make this choice by selecting an instance configuration, which determineswhere your data is stored for that instance:

• Regional configurations: all the resources residewithin a single Google Cloud region
• Dual-region configurations: all resources spantwo regions and reside within a single country (available in theEnterprise Plus edition)
• Multi-region configurations: the resourcesspan more than two regions (available in theEnterprise Plus edition)

For more information about region-specific considerations, seeGeography and regions.

The instance configurations with predefined regions and replication topologiesare referred to asbase instance configurations. You can createcustom instance configurations and add additional optional read-onlyreplicas to a predefined base instance configuration (available in theEnterprise edition and Enterprise Plus edition).The added read-only replica must be in a region that isn't part of the existinginstance configuration. For a list of the optional read-only regions that youcan add, see the Optional Region column underRegional available configurationsandMulti-region available configurations.You can't change the replication topology of base instance configurations. Formore information, seeRead-only replicas.

You canmove your instancefrom any instance configuration to any other regional, dual-region ormulti-region instance configuration (for example, fromregional-us-central1 tonam3). You can alsocreate a new custom instance configuration withadditional replicas,then move your instance to the new custom instance configuration. For example,if your instance is inregional-us-central1 and you want to add a read-onlyreplicaus-west1, then you need to create a new custom instance configurationwithregional-us-central1 as the base configuration and addus-west1 as aread-only replica. Then, move your instance to this new custom instanceconfiguration.

Regional configurations

Google Cloud services are available inlocations across NorthAmerica, South America, Europe, Asia, and Australia. If your users and servicesare located within a single region, choose a regional instance configuration forthe lowest-latency reads and writes.

For any base regional configuration, Spanner maintains threeread-write replicas, each within a different Google Cloudzone in that region. Each read-write replica containsa full copy of your operational database that is able to serve read-write andread-only requests. Spanner uses replicas in different zones sothat if a single-zone failure occurs, your database remains available.

Available configurations

Spanner offers the following base regional instanceconfigurations. To request an optional read-only replica region that isn'tlisted in the following table,fill out this request form.Note that we use these requests to gauge demand for future regions and may notrespond directly to your submission.

Replication

Base regional configurations contain threeread-write replicas. Every Spannermutation requires a write quorum that's composed of a majority of votingreplicas. Write quorums are formed from two out of the three replicas inregional configurations. For more information about leader regions and votingreplicas, seeReplication.

You cancreate a custom regional instance configurationand add optional read-only replicas. Read-only replicas can help scale reads andsupport low latency stale reads. These read-only replicas don't take part inthe write quorums.The replicas don't affect theSpanner >= 99.99% SLA for regional instances.You can add locations listed under the Optional Region column as optionalread-only replica(s). If you don't see your chosen read-only replica location,you canrequest a new optional read-only replica region.For more information, seeRead-only replicas.

Performance best practices for regional configurations

For optimal performance, follow these best practices:

• Design a schema that prevents hotspots and other performanceissues.
• Place critical compute resources within the same region as yourSpanner instance.
• Provision enoughcompute capacity to keephigh priority total CPU utilization under 65%.
• For information about the amount of throughput per Spannernode, seePerformance for regional configurations.

Dual-region configurations

Note: Dual-region configurations are available with theSpanner Enterprise Plus edition. For more information, see theSpanner editions overview.

Dual-region configurations let you replicate the database's data inmultiple zones across two regions in a single country, as defined by theinstance configuration.

Dual-region configurations do the following:

• Serve reads from two regions in a single country.
• Meet data residency requirements.
• Provide higher availability and SLAs than regional configurations.

Spanner offers dual-region configurations in Australia,Germany, India, and Japan.

For information about the amount of throughput per Spanner node,seePerformance for dual-region configurations.

Available configurations

Spanner offers the following base dual-region instanceconfigurations:

Benefits

Dual-region instances offer these primary benefits:

• 99.999% availability: across two regions in the same country, which isgreater than the 99.99% availability that Spanner regionalconfigurations provide.

• Data distribution: automatically replicates your data between the tworegions with strong consistency guarantees.

• Data residency requirements: Meets data residency requirements in thecountries listed under dual-regionAvailable configurations.

Replication

A dual-region contains six replicas, three in each region. One of the regionsis designated as the default leader region (listed in the previous table). Youcanchange the leader region of a database.In each region, there are two read-write replicas and onewitness replica. When both regions arehealthy and running in a dual-region configuration, the quorum isestablished across all six replicas. A minimum of two replicas in eachregion is required to form a quorum and commit a transaction.

Failover and failback

After you create a dual-region configuration, you can view theDual-region quorum health timeline metric on theSystem insightsdashboard. This metric is only available for dual-region configurations. Itshows the health of three quorums:

• The dual-region quorum:Global
• The single region quorum in each region (for example,Sydney andMelbourne)

It shows an orange bar in the timeline when there is service disruption. You canhover over it to see the start and end times of the disruption.

For faster recovery time objective (RTO), we recommend monitoring or setting upan alert on the dual-region quorum health timeline metric. This metric helps youmake self-managed, when-to-failover decisions in case of regional failures.After you trigger instance failover, the failover usually completes within oneminute.

Spanner also supports automatic, Google-managed failovers, whichmight take up to 45 minutes from the time the failure is first detected. Thelonger RTO is due to Google's service-wide monitoring. We need to gatheradditional signals to verify that the entire region is disrupted and validatethat there is region-level impact. This also ensures that a failover results inbetter overall service for users in the configuration.

To failover and failback manually, seeChange dual-region quorum.

Consider the following when making manual failover and failback decisions:

• If all three quorums are healthy, then no action is needed.

• If one of the regions shows disruption, then there is probably a regionalservice disruption. This might cause the databases running in yourdual-region quorum to experience less availability. Writes might also failbecause a quorum can't be established and transactions eventually time out.Using the System insights dashboard, observe error rates and latency in yourdatabase. If there are increased error rates or latency, then we recommendthat youfailover, which means changing the dual-region quorum fromdual-region to the region that is still healthy. After the disrupted regionis healthy again, you mustfailback, changing the dual-region quorum fromsingle region to dual-region. Google automatically performs failover andfailback when it detects a regional outage. You can also manually failoverif you detect a disruption. However, you must remember to manually failbackif you performed a manual failover.

• If the dual-region quorum shows disruption even though both single regionsare healthy, then there is a network partitioning issue. The two regions areno longer able to communicate with each other so they each show healthy eventhough the overall system is not. In this scenario, we recommend that youfailover to the default leader region. After the network partition issue isresolved and the dual-region quorum returns to healthy, you must manuallyfailback.

Dual-region provides zero recovery point objective (RPO) because there is nodata loss during a regional outage or when a network partition issue arises.

To check the mode (single or dual) of your dual-region quorum, seeCheck dual-region quorum.

Failover and failback best practices

Failover and failback best practices include:

• Don't failover to a single region if no region failures or disruptionsoccur. Failing over to a single region increases the possibility of overallsystem unavailability if that single region fails.
• Be mindful when selecting the region to failover. Choosing a wrong region tofailover results in database unavailability, which is unrecoverable beforethe region is back online. To verify, you can use abash scriptto check the health of your single region, before performing the failover.
• If the unhealthy region is the default leader region,change the default leader regionto the failover region after performing the failover. After confirming bothregions are healthy again, perform failback, then change the leader regionback to your original leader region.
• Remember to manually failback if you performed a manual failover.

Limitations

You can't create a custom dual-region instance configuration. You can't addread-only replicas to a dual-region instance configuration.

Multi-region configurations

Note: Multi-region configurations are available with theSpanner Enterprise Plus edition. For more information, see theSpanner editions overview.

Spanner regional configurations replicate data between multiplezones within a single region. However, a regional configuration might not beoptimal if:

• Your application often needs to read data from multiple geographiclocations (for example, to serve data to users in both North America andAsia).
• Your writes originate from a different location than your reads (forexample, if you have large write workloads in North America and large readworkloads in Europe).

Multi-region configurations can:

• Serve writes from multiple regions.
• Maintain availability in the case of regional failures.
• Provide higher availability and SLAs than regional configurations.

Multi-region configurations let you replicate your databases in multiple zonesacross multiple regions, as defined by the instance configuration. Eachmulti-region configuration contains two read-write regions. A read-write regioncontains two read-write replicas located in separate zones. These replicas letyou read data with lower latency from multiple locations close to or within theregions in the configuration.

There are trade-offs though, because in a multi-region configuration, the quorum(read-write) replicas are spread across more than one region. You might noticeadditional network latency when these replicas communicate with each other toform a write quorum. Reads don't require a quorum. The result is that yourapplication achieves faster reads in more places at the cost of a small increasein write latency. For more information, seeThe role of replicas in writes and reads.

Available configurations

Spanner offers the following base multi-region instanceconfigurations. To request an optional read-only replica region that isn'tlisted in the following table,fill out this request form.Note that we use these requests to gauge demand for future regions and may notrespond directly to your submission.

One continent

Three continents

• L: default leader region. For more information, seeModify the leader region of a database.

• 1R: one replica in the region.

• 2R: two replicas in the region.

• 2RW+1W: two read-write replicas and one witness replica in the region.

• 1-OR: one optional replica. You can create a custom regional instance configuration and add one optional read-only replica. For more information, seeCreate a custom instance configuration.

• 2-OR: up to two optional replicas. You can create a custom regional instance configuration and add one or two optional read-only replicas. We recommend adding two (where possible) to help maintain low read latency. For more information, seeCreate a custom instance configuration.

• A: This instance configuration is restricted with an allow-list. To get access, reach out to your Technical Account Manager.

The resource location for a multi-region instance configuration determines thedisaster recovery zone guarantee for the configuration. It defines where data isstored at-rest.

Benefits

Multi-region instances offer these primary benefits:

• 99.999% availability, which is greater than the 99.99% availability thatSpanner regional configurations provide.

• Data distribution: Spanner automatically replicates yourdata between regions with strong consistency guarantees. This allows your datato be stored where it's used, which can reduce latency and improve the userexperience.

• External consistency: Even though Spanner replicates acrossgeographically distant locations, you can still use Spanner as if itwere a database running on a single machine. Transactions are guaranteed to beserializable, and the order of transactions within the database is the same asthe order in which clients observe the transactions to have been committed.External consistency is a stronger guarantee than "strong consistency," whichis offered by some other products. Read more about this property inTrueTimeand external consistency.

Replication

Each base multi-region configuration contains two regions thatare designated asread-write regions, each of which contains two read-writereplicas. One of these read-write regions is designated as thedefault leaderregion, which means that it contains your database's leader replicas.Spanner also places a witness replica in a third region called awitness region.

Each time a client issues a mutation to your database, a write quorum forms,consisting of one of the replicas from the default leader region and any two ofthe additional four voting replicas. (The quorum could be formed by replicasfrom two or three of the regions that make up your configuration, depending onwhich other replicas participate in the vote.) In addition to these five votingreplicas, some base multi-region configurations contain read-onlyreplicas for serving low-latency reads. The regions that contain read-onlyreplicas are calledread-only regions.

In general, the voting regions in a multi-region configuration are placedgeographically close—less than a thousand miles apart—to form alow-latency quorum that enables fast writes (learnmore). However, the regions are still far enoughapart—typically, at least a few hundred miles—to avoid coordinatedfailures. In addition, if your client application is in a non-leaderregion, Spanner uses leader-aware routing to routeread-write transactions dynamically to reduce latency in your database. For moreinformation, seeLeader-aware routing.

You cancreate a custom multi-region instance configurationwith optional read-only replicas. Any custom read-only replicas you createcan't be included in write quorums. You can add locations listed under theOptional Region column as optional read-only replica(s). If you don't see yourchosen read-only replica location, you canrequest a new optional read-only replica region.For more information, seeRead-only replicas.

Note: if you are interested in more detailed information about how data isreplicated in Spanner, and about the different types of replicas andtheir roles in reads and writes, seeReplication.

Performance best practices for multi-region configurations

For optimal performance, follow these best practices:

• Design a schema that prevents hotspots and other performanceissues.
• For optimal write latency, place compute resources for write-heavy workloadswithin or close to the default leader region.
• For optimal read performance outside of the default leader region, usestaleness of at least 15 seconds.
• To avoid single-region dependency for your workloads, place critical computeresources in at least two regions. A good option is to place them next to thetwo different read-write regions so that any single region outage won'timpact all of your application.
• Provision enoughcompute capacity to keephigh priority total CPU utilization under 45%in each region.
• For information about the amount of throughput per Spannernode, seePerformance for multi-region configurations.

Move an instance

You can move your Spanner instance from any instanceconfiguration to any other instance configuration, including between regionaland multi-region configurations. Moving your instance does not cause downtime,and Spanner continues to provide the usualtransactionguarantees,including strong consistency, during the move.

To learn more about Spanner instance move, seeMove an instance.

Configure the default leader region

To change the location of your database's default leader region to be closer toconnecting clients to reduce application latency, you can change the leaderregion for any Spanner instance that uses a dual-region ormulti-region configuration. For instructions on changing the location of theleader region, seeChange the leader region of a database.The only regions eligible to become the default leader region for your databaseare the read-write regions in yourdual-regionormulti-regionconfiguration.

The leader region is responsible for handling all database writes, therefore ifmost of your traffic comes from one geographic region, youcan move it to that region to reduce latency. Updating the default leaderregion is cheap and does not involve any data moves. The new value takes a fewminutes to take effect.

Note: In the event that the default leader region fails or is not available,Spanner automatically places your database's leader replicas in thesecond read-write region of your instance configuration, ensuring highavailability and no impact to your application.

Changing the default leader region is aschema change,which uses a long-running operation. If needed, you canGet the status of the long-running operation.

Trade-offs: regional versus dual-region versus multi-region configurations

Configuration	Availability	Latency	Cost	Data Locality
Regional	99.99%	Lower write latencies within region.	Lower cost; seepricing.	Enables geographic data governance.
Dual-region	99.999%	Lower read latencies from two geographic regions; a small increase in write latency.	Higher cost; seepricing.	Distributes data across two regions in a single country.
Multi-region	99.999%	Lower read latencies from multiple geographic regions; a small increase in write latency.	Higher cost; seepricing.	Distributes data across multiple regions within the configuration.

What's next

• Learn how tocreate a Spanner instance.
• Learn more aboutGoogle Cloud geography and regions.