This section provides recommended patterns for running CockroachDB in a cloud environment.
You can observe latency for your cluster on the Network Latency page of the DB Console.
When your clients are in a single geographic region, choosing a pattern is straightforward.
When your clients are in multiple geographic regions, it is important to deploy your cluster across regions properly and then carefully choose:
Not doing so can result in unexpected latency and resiliency. For more information, see the Multi-Region Capabilities Overview.
The multi-region patterns described below are almost always table-specific. For example, you might use Regional Tables for frequently updated tables that are tied to a specific region, and Global Tables for reference tables that are not tied to a specific region, and that are read frequently but updated infrequently.
|Regional Tables||Low latency for single-region writes and multi-region stale reads.|
|Global Tables||Low-latency multi-region reads from all regions, at the expense of higher latency cross-region writes.|
|Follower Reads||Fast regional (historical) reads, slower cross-region writes.|
|Follow-the-Workload||Fast regional reads in the active region; slower cross-region reads elsewhere. Slower cross-region writes.|
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.,
europe) using only the default Follow-the-Workload behavior. In this case, latency will likely be unacceptably high.