You can observe latency for your cluster on the Network Latency page of the DB Console.
Single-region
When your clients are in a single geographic region, choosing a topology pattern is straightforward.Multi-region
When your clients are in multiple geographic regions, it is important to deploy your cluster across regions properly and then carefully choose the right:- Survival goal for each database.
- Table locality for each table.
In multi-region databases, the resiliency of each database depends on its survival goal settings.
REGIONAL tables (the default locality). However, there are two reasons you might want to upgrade a table to GLOBAL:
- You want low-latency consistent (non-stale) read access to the table in multiple regions from read-write transactions. One case where this is important is if the table is referenced by a foreign key from a
REGIONAL BY ROWtable. In these cases, the foreign key check that accompanies a write cannot use a stale read because it must be transactionally consistent with the write. To keep this foreign key check fast, you can make the reference tableGLOBAL, at the expense of slower writes to that table. - When an ORM or application-level tool makes follower reads too hard to use. In these cases,
GLOBALtables can allow you to achieve low-latency reads through a schema-level setting.
GLOBAL tables when you can’t.
Anti-patterns
The following anti-patterns are ineffective or risky:- Single-region deployments using 2 zones, or multi-region deployments using 2 regions. In these cases, the cluster would be unable to survive the loss of a single zone or a single region, respectively.
- Broadly distributed multi-region deployments (e.g.,
us-west,asia, andeurope) using only the default Follow-the-Workload behavior. In this case, latency will likely be unacceptably high.
See also
- Multi-Region Capabilities Overview
- How to Choose a Multi-Region Configuration
- When to Use
ZONEvs.REGIONSurvival Goals - When to Use
REGIONALvs.GLOBALTables - Low Latency Reads and Writes in a Multi-Region Cluster
- Migrate to Multi-Region SQL
- Secondary regions
ALTER DATABASE ... SET SECONDARY REGIONALTER DATABASE ... DROP SECONDARY REGION- Topology Patterns Overview
- Single-region patterns
- Multi-region patterns

