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.

Note:

Multi-region patterns are almost always table-specific. For example, you might use the Geo-Partitioning pattern for frequently updated tables that are geographically specific and the Duplicate Indexes pattern for infrequently updated tables (e.g., reference tables) that are not tied to geography.

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.


Yes No