> ## 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. # Multi-Region Zone Config Extensions 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} ; }; Multi-Region *Zone Config Extensions* are a customization tool for advanced users to persistently modify the configuration generated by the standard multi-region SQL abstractions on a per-region basis. They are controlled using the `ALTER DATABASE ... ALTER LOCALITY` statement. Use cases for Zone Config Extensions include: * Failover behavior * Regions with stale read access * Quorum placement * Data domiciling We strongly recommend that most users use the default multi-region SQL abstractions as much as possible. However, if you need additional customizations, using Zone Config Extensions is better than writing your own low-level zone configs for the following reasons: * Zone Config Extensions are persistent and kept up-to-date. Unlike raw zone config modification, which must be fully overwritten on each multi-region configuration change in order to take effect, Zone Config Extensions stay in place alongside the high-level multi-region SQL configuration. This is true even if you add new tables or regions, or if a table's locality is changed. * They are validated against the configs already in place in a multi-region cluster. Unlike hand-written zone configs, they are designed to work properly with the configuration generated by the higher-level multi-region SQL statements. Specifically, this means: * `REGIONAL` extensions don't set lease preferences. * `REGIONAL IN` extensions don't set lease preferences, nor do they set replica constraints or voter constraints that would conflict with the original home region. * In no case will Zone Config Extensions change the survival goals for the database. * Zone Config Extensions can set `num_replicas` as low as `num_voters`, which removes non-voting replicas while preserving the database's survival goal. * They are composable. You can use Zone Config Extensions to build up approximations of many higher-level features. For an example, see Failover regions. * They are region scoped. When a Zone Config Extension is attached to a database region, any `REGIONAL BY TABLE` or `REGIONAL BY ROW` tables associated with that region will have their zone configurations updated according to the settings passed via the extension. As mentioned above, this updated config will also be persisted in the face of other multi-region configuration changes. * They are locality scoped. You can specify a Zone Config Extension that only applies to tables with certain localities. For example, to apply a Zone Config Extension to tables with the `GLOBAL` locality, use `ALTER DATABASE ... ALTER LOCALITY GLOBAL ...`. Zone Config Extensions are a property of a database region, *not* any particular schema object. This differs from raw zone configurations, which may need to be assigned (and reassigned) to 10s or 100s of different schema objects on every configuration change. For instructions showing how to use Zone Config Extensions, see Use Zone Config Extensions. ## See also * Use Zone Config Extensions * `ALTER DATABASE ... ALTER LOCALITY` * Multi-Region Capabilities Overview * Data Domiciling * `PLACEMENT RESTRICTED` * `SET LOCALITY` * `ADD REGION` * `SET PRIMARY REGION` * [Troubleshoot Replication Zones](/docs/v26.2/troubleshoot-replication-zones)