Choosing a multi-region configuration

This page has high-level information about how to configure a multi-region cluster's survival goals and table locality.

The options for configuring your multi-region cluster include:

• Change nothing: Using the default settings, you get:

  • Zone survival (the default).
  • Low-latency reads and writes from a single region.
  • A choice of low-latency stale reads or high-latency fresh reads from other regions (and high-latency fresh reads is the default).

• Change only survival goals: This configuration is useful for single-region apps that need higher levels of survival. In this configuration, you move from availability zone (AZ) survival to get:

  • Region survival.
  • Low-latency reads from a single region.
  • A choice of low-latency stale reads or high-latency fresh reads from other regions (and high-latency fresh reads is the default).
  • Higher-latency writes from all regions (due to region survival).

• Change only table locality: This is useful for multi-region apps that require different read/write latency guarantees for different tables in the database, and are not concerned with surviving a region failure. In this configuration, you get:

  • Zone survival (the default).
  • For global tables, low-latency reads from all regions.
  • For regional by row tables, low-latency reads and writes from each row's home region, and low-latency follower reads from all other regions.

• Change both survival goals and table locality: This is useful for multi-region apps that want a high level of survival. In this configuration, you move from zone survival and get:

  • Region survival.
  • Low-latency reads from all regions.
  • Higher-latency writes from all regions (due to region survival).

The table below offers another view of how the configuration options described above map to:

• The performance characteristics of specific survival goal/table locality combinations.
• The types of applications that can benefit from each combination.

locality ↓ survival →	ZONE	REGION
REGIONAL BY TABLE	Low-latency for single-region writes and multi-region stale reads.	Single-region writes are higher latency than for ZONE, as at least one additional region must be consulted for each write. Stale multi-region reads are of comparable latency to ZONE survival.
	For single-region apps that can accept risk of region failure.	For single-region apps that must survive region failure.
REGIONAL BY ROW	Low-latency consistent multi-region reads & writes for rows which are homed in specific regions.	Low-latency consistent reads from a row's home region. Low-latency consistent stale reads from outside the row's home region. Low-latency writes if you are writing to a row from its home region.
	For multi-region apps which read/write individual rows of the table from a specific region, and can accept the risk of region failure.	Same as for ZONE survival, but for apps that must survive a region failure.
GLOBAL	Low-latency multi-region reads. Writes are higher latency than reads.	Low-latency multi-region reads. Writes are higher latency than reads. There should be minimal difference in write latencies between ZONE and REGION survival due to a new custom non-blocking transaction protocol.
	For multi-region apps that need low-latency reads of a "read-mostly" table.	For multi-region apps that need low-latency reads of a "read-mostly" table, and the ability to survive region failures.

See also

• Multi-region overview
• When to use REGIONAL vs. GLOBAL tables
• When to use ZONE vs. REGION survival goals
• Topology Patterns
• Disaster Recovery
• Multi-region SQL performance