Topology Patterns

This section provides recommended topology patterns for running CockroachDB in a cloud environment, each with required configurations and latency and resiliency characteristics.

Single-region patterns

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

Pattern	Latency	Resiliency	Configuration
Development	Fast reads and writes	None	1 node No replication
Basic Production	Fast reads and writes	1 AZ failure	1 region 3 AZs 3+ nodes across AZs

Multi-region patterns

When your clients are in multiple geographic regions, it is important to deploy your cluster across regions properly and then carefully choose the right topology for each of your tables. Not doing so can result in unexpected latency and resiliency.

Pattern	Latency	Resiliency	Configuration
Geo-Partitioned Replicas	Fast regional reads and writes	1 AZ failure per partition	Geo-partitioned table Partition replicas pinned to regions
Geo-Partitioned Leaseholders	Fast regional reads Slower cross-region writes	1 region failure	Geo-partitioned table Partition replicas spread across regions Partition leaseholders pinned to regions
Duplicate Indexes	Fast regional reads (current) Much slower cross-region writes	1 region failure	Multiple identical indexes Index replicas spread across regions Index leaseholders pinned to regions
Follower Reads	Fast regional reads (historical) Slower cross-region writes	1 region failure	App configured to use follower reads
Follow-the-Workload	Fast regional reads (active region) Slower cross-region reads (elsewhere) Slower cross-region writes	1 region failure	None

Anti-patterns

The following anti-patterns are ineffective or risky:

• Single-region deployments using 2 AZs, or multi-region deployments using 2 regions. In these cases, the cluster would be unable to survive the loss of a single AZ or a single region, respectively.
• Broadly distributed multi-region deployments (e.g., us-west, asia, and europe) using only the default Follow-the-Workload pattern. In this case, latency will likely be unacceptably high.
• Geo-partitioned tables with non-partitioned secondary indexes. In this case, writes will incur cross-region latency to achieve consensus on the non-partitioned indexes.