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.

Note:

This is an enterprise-only feature. Request a 30-day trial license to try it out.

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.
    • Low-latency stale reads from all other regions.
  • 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.
    • Low-latency stale reads from all other regions.
    • 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:

  • 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 multi-region reads. Low-latency single-region 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.
Note:

Different databases and tables within the same cluster can each use different combinations of the settings above.

See also

YesYes NoNo