> ## Documentation Index
> Fetch the complete documentation index at: https://cockroachlabs.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
# How to Choose a Multi-Region Configuration
export const InternalLink = ({version, path = "", children, ...props}) => {
let detectedVersion = version || "stable";
if (typeof window !== 'undefined' && !version) {
const match = window.location.pathname.match(/\/docs\/([^/]+)/);
if (match) {
detectedVersion = match[1];
}
}
const normalizedPath = path.startsWith("/") ? path.slice(1) : path;
return
{children}
;
};
This page has high-level information about how to configure a multi-region cluster's survival goals and table localities.
## Multi-region configuration options
The options for configuring your multi-region cluster include:
* *Change nothing*: Using the default settings, you get:
* Zone survival (the default).
* Low-latency reads and writes from a single region.
* A choice of low-latency stale reads or high-latency fresh reads from other regions (and high-latency fresh reads is the default).
* *Change only survival goals*: This configuration is useful for single-region apps that need higher levels of survival. In this configuration, you move from availability zone (AZ) survival to get:
* Region survival.
* Low-latency reads from a single region.
* A choice of low-latency stale reads or high-latency fresh reads from other regions (and high-latency fresh reads is the default).
* Higher-latency writes from all regions (due to region survival).
* *Change only table localities*: This is useful for multi-region apps that require different read and write latency guarantees for different tables in the database, and are not concerned with surviving a region failure. In this configuration, you get:
* Zone survival (the default).
* For global tables, low-latency reads from all regions.
* For regional by row tables, low-latency reads and writes from each row's home region, and low-latency follower reads from all other regions.
* *Change both survival goals and table localities*: This is useful for multi-region apps that want a high level of survival. In this configuration, you move from zone survival and get:
* Region survival.
* Low-latency reads from all regions.
* Higher-latency writes from all regions (due to region survival).
## Configuration options vs. performance characteristics and application styles
The following table offers another view of how the various configuration options map to:
* The performance characteristics of specific survival goal and table locality combinations.
* The types of applications that can benefit from each combination.
| locality ↓ survival → | `ZONE` | `REGION` |
| --------------------- | ------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `REGIONAL BY TABLE` | Low-latency for single-region writes and multi-region stale reads. | Single-region writes are higher latency than for `ZONE`, as at least one additional region must be consulted for each write. Stale multi-region reads are of comparable latency to `ZONE` survival. |
| | Single-region apps that can accept region failure. | Single-region apps that must survive region failure. |
| `REGIONAL BY ROW` | Low-latency consistent multi-region reads and writes for rows that are homed in specific regions. | Low-latency consistent reads from a row's home region. Low-latency consistent stale reads from outside the row's home region. Higher-latency writes if writing to a row from outside its home region. |
| | Multi-region apps that read and write individual rows of the table from a specific region and can accept region failure. | Multi-region apps that read and write individual rows of the table from a specific region and must survive a region failure. |
| `GLOBAL` | Low-latency multi-region reads. Writes are higher latency than reads. | Low-latency multi-region reads. Writes are higher latency than reads. There should be minimal difference in write latencies between `ZONE` and `REGION` survival. |
| | Multi-region apps that need low-latency reads of a "read-mostly" table. | Multi-region apps that need low-latency reads of a "read-mostly" table and must survive a region failure. |
Different databases and tables within the same cluster can each use different combinations of these settings.
For new clusters using the multi-region SQL abstractions, Cockroach Labs recommends lowering the `--max-offset` setting to `250ms`. This setting is especially helpful for lowering the write latency of global tables. Nodes can run with different values for `--max-offset`, but only for the purpose of updating the setting across the cluster using a rolling upgrade.
## See also
* Multi-Region Capabilities Overview
* When to Use `REGIONAL` vs. `GLOBAL` Tables
* When to Use `ZONE` vs. `REGION` Survival Goals
* [Survive Region Outages with CockroachDB](https://www.cockroachlabs.com/blog/under-the-hood-multi-region/)
* Topology Patterns
* Disaster Recovery
* Low Latency Reads and Writes in a Multi-Region Cluster
* Secondary regions
* `SET SECONDARY REGION`
* `DROP SECONDARY REGION`