- Failover behavior
- Regions with stale read access
- Quorum placement
- Data domiciling
- 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 . This is true even if you or , or if a table’s .
- 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:
- extensions don’t set .
- extensions don’t set , nor do they set or that would conflict with the original .
- In no case will Zone Config Extensions change the for the database.
- Zone Config Extensions can set as low as , 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 .
- They are region scoped. When a Zone Config Extension is attached to a , any or 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 . For example, to apply a Zone Config Extension to tables with the , use .
Zone Config Extensions are a property of a , not any particular . This differs from raw , which may need to be assigned (and reassigned) to 10s or 100s of different schema objects on every configuration change.