Topology Patterns Overview

This page describes recommended topology patterns for running CockroachDB in a cloud environment and the expected impacts of these patterns on latency and resiliency.

You can observe latency for your cluster on the of the DB Console.

Single-region

When your clients are in a single geographic region, choosing a topology pattern is straightforward.

Deployment Type	Latency	Resiliency	Configuration
Development	Fast reads and writes	None	1 node No replication
	Fast reads and writes	1 zone failure	1 region 3 zones 3+ nodes across zones

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:

• for each database.
• for each table.

Failure to consider either of these aspects can result in unexpected impacts on latency and resiliency. For more information, see the .

The multi-region patterns described in the following table are almost always table-specific. For example, you might use for frequently updated tables that are tied to a specific region, and for reference tables that are not tied to a specific region, and that are read frequently but updated infrequently.

Pattern	Latency
	Low latency for single-region writes and multi-region stale reads.
	Low-latency multi-region reads from all regions, at the expense of higher latency cross-region writes.
	Fast regional (historical) reads, slower cross-region writes.
	Fast regional reads in the active region; slower cross-region reads elsewhere. Slower cross-region writes.

In , the resiliency of each database depends on its .

If you want low-latency read-only access to your data in multiple regions, Cockroach Labs recommends that you default to using stale follower reads on 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 from a table. 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 table GLOBAL, at the expense of slower writes to that table.
• When an or application-level tool makes follower reads too hard to use. In these cases, GLOBAL tables can allow you to achieve low-latency reads through a schema-level setting.

In summary, Cockroach Labs recommends that you use follower reads whenever you can, and use GLOBAL tables when you can’t.

In the following demo, we show the importance of choosing the correct topology patterns for your tables:

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, and europe ) using only the default behavior. In this case, latency will likely be unacceptably high.

See also

• • Single-region patterns
  • Multi-region patterns