CockroachDB 26.3 gives super regions their own survival goals
A super region can now choose a failure-survival objective independently of its database default. The useful distinction is between keeping replicas in a group of regions and keeping their quorum available through a failure.
Keeping replicas inside a geographic boundary and keeping data available after a region fails are different requirements. CockroachDB 26.3 makes super regions generally available with independent survival goals, so those requirements can be expressed for a subset of a database's regions. The August 19 release notes describe a super region as a group that keeps its data replicas within its member regions, with its own zone configuration and survival objective.
The change matters when one database covers geographic groups with different placement needs. A database-wide default remains available, but an explicitly configured super region no longer has to follow later changes to that default. The configuration can state a local failure objective instead of making it an indirect consequence of the database's current setting.
I value CockroachDB's explicit consistency model and accept the latency cost of consensus when the required guarantees justify it. Super regions fit that preference because they make another architectural decision visible. The places where copies may reside and the failures those copies must tolerate need a relationship that can be inspected, rather than an assumption inferred from a map of deployment locations.
A super region applies to data with a home region
The multi-region overview defines which data falls under the rule. A regional table whose home region belongs to a super region has its replicas stored in that group. For a regional-by-row table, the rule applies to rows whose home region belongs to the group. This makes the data's locality assignment part of the placement decision.
That scope is more precise than saying the entire cluster is divided into isolated geographic databases. The feature operates through database regions and table localities. Understanding which table or row has which home region is necessary to explain which super-region rule governs its copies. A grouping name alone does not identify all data in the cluster that might be relevant to an application.
The member regions must already exist in the database. Each region can belong to only one super region, so two groups cannot overlap. A region cannot be dropped while it belongs to a super region without first changing or removing that grouping. These rules keep the configuration from assigning one region to competing group definitions or deleting a member through an unrelated operation.
Both voting and non-voting replicas are covered by the placement rule. The documentation contrasts this with PLACEMENT RESTRICTED, which removes non-voting replicas. That distinction is important because restricting the set of locations is a different operation from eliminating a class of copies. A super region can retain copies useful for reads while constraining them to the intended group.
An explicit survival goal stops inheritance
By default, a super region inherits its database's survival goal. Version 26.3 lets it choose ZONE or REGION independently. The ALTER DATABASE reference gives the following form for an existing database named movr with an existing super region named usa.
ALTER DATABASE movr
ALTER SUPER REGION "usa"
SURVIVE ZONE FAILURE;
Once that explicit goal is set, later changes to the database default do not change it. This is an inheritance rule with a practical consequence for configuration management. Editing the default does not necessarily update every group. The effective configuration includes both inherited values and local choices, and the latter require their own inspection.
The reference documents SHOW SUPER REGIONS FROM DATABASE for viewing explicit goals. It also provides a way to return to inheritance.
ALTER DATABASE movr
ALTER SUPER REGION "usa"
SURVIVE DEFAULT;
That reset is validated against what the super region can support. A group with fewer than three regions cannot inherit a region-survival goal. The command fails instead of accepting a configuration whose membership cannot meet the requested objective. Reverting to a default is therefore an operation that can have a real precondition, not merely deletion of a local setting.
Region survival needs enough regions inside the group
The overview says a super region with at least three member regions and a region-survival goal can keep its domiciled data available when one region fails. The placement boundary must contain enough regions for that objective. Adding a region outside the super region does not satisfy the stated membership requirement for the group.
This creates a tangible topology tradeoff. A grouping selected only to constrain geography may have too few distinct regions for regional failure tolerance. The new independent goal makes that mismatch expressible and checkable. It does not make a small group capable of an objective that requires a larger one.
The distinction is useful when different parts of an application have different placement requirements. A configuration can retain a zone-survival goal for one group and a region-survival goal for another, subject to the documented membership rules. The release does not establish that these choices have identical cost or latency. Their purpose is to express different availability requirements within their respective placement constraints.
For me, the value is in being able to state the intended failure tolerance without pretending every geographic group has the same topology. The resulting design is more specific than a general claim that the database is multi-region. It identifies which data belongs to which group and the failure class that group is configured to survive.
Data quorum does not establish whole-cluster availability
The overview explicitly warns that a super region's survival goal does not alter replica placement for the system database. If system ranges lose quorum, cluster availability can suffer even when the super region's own data remains available. This is a dependency outside the local data-placement rule, and it limits what a successful local failure assessment can establish.
A test proving that application data retains its replicas is therefore only part of the availability argument. The cluster also needs the system state on which service depends. This is a substantive architecture boundary, not a reason to disregard the feature. The documentation makes clear that a per-group objective does not automatically redefine every other range's failure tolerance.
Secondary-region configuration has related constraints. If the database primary is inside a super region, its secondary must be within that same group. If the primary is outside all super regions, the secondary must also remain outside them. The failover preference cannot be chosen independently of the placement grouping under these rules.
The documentation also qualifies the strength of the placement controls. Super regions use the underlying replication-zone system, whose top priority is preventing data loss. It says the replication system may override zone configurations when necessary to preserve durability. That qualification belongs in any technical description of the guarantee. The feature's ordinary placement policy is not an unconditional statement about every emergency durability decision.
Changing the primary region has a separate protection. The reference says a primary inside a super region cannot be changed by default, to avoid accidentally moving a regional table's data outside its intended group. An explicit override is available for that operation. The protected default shows why routine configuration changes need to account for data locality, since moving a database role such as the primary can affect placement even when the super-region membership list itself has not been edited.
PostgreSQL compatibility is another explicit boundary in this release
Version 26.3 also reports PostgreSQL version 18 to clients and aligns pg_catalog with that version's system catalogs. The release describes this as reducing errors with current drivers, ORMs and tools. It is a compatibility target for client behavior, not a statement that CockroachDB has become the PostgreSQL storage or replication implementation.
The same release adds DOMAIN types, defined as user-created types based on an existing type with optional constraints and defaults. That is a concrete schema capability whose usefulness can be assessed separately from the reported server version. A tool that recognizes the version may still need to account for the database's actual supported operations and distributed architecture.
Schema export gains support for PostgreSQL 18's pg_dump. The notes distinguish recreating a schema in another CockroachDB database from generating PostgreSQL-oriented definitions. As with super-region settings, the useful contract is the specific operation described. A successful schema export does not transfer the source cluster's region placement or prove equivalent availability in another database engine.
The super-region change remains the part that most directly affects architectural planning. An explicit goal persists through changes to the database default, while resetting it requires the group to satisfy the inherited goal. That gives configuration review an observable result, with the system-database dependency and documented durability exception retained in the description of what the placement policy provides.