Multi-region deployments are often motivated by resilience: If a region goes down, your system should keep serving traffic. But resilience is only part of the story.
In practice, teams also care about where data is allowed to live (for domiciling and compliance) and about keeping access latency low, even when the system is under stress and making failover or rebalancing decisions. The challenge of designing multi-region database architecture is that these goals cut across replica placement and query planning, and it's not easy to expose that complexity in a way developers can reason about.
Cockroach Labs was recently awarded three US patents (authored by myself and several Cockroach Labs colleagues) that address these problems:
US Patent 12,561,342 – "Multi-Region Database Systems and Methods"
US Patent 12,499,127 – "Systems and Methods for Controlling Replica Placement in Multi-Region Databases"
US Patent 12,488,000 – "Systems and Methods for Locality-Aware Query Optimization"
The first patent defines the SQL-level abstractions that the other two build on; the second addresses controlling where replicas live, including for data domiciling and failover; and the third makes the query engine geography-aware.
As Director, Engineering at Cockroach Labs, I lead the SQL Queries and Specialized Indexing teams, where we build SQL abstractions to help developers reason clearly about multi-region systems. In this article, I'll walk through all three patents, starting with the foundational SQL abstractions and then showing how the two follow-on patents build on them for placement control and query planning. If you're new to CockroachDB multi-region, the Multi-Region Capabilities Overview is a good place to start.
Multi-Region SQL Abstractions for Database Architecture (US Patent 12,561,342)
Why SQL abstractions simplify multi-region database architecture
A multi-region database is a distributed system that replicates data across regions. This improves availability, enforces data residency, and reduces user-facing latency. It enables global scale by keeping applications fast, available, and compliant across regions.
Multi-region systems have historically required users to reason about low-level mechanisms: replica counts, placement constraints, rebalancing heuristics, and failure behavior. Each of these is important, but configuring them individually is error-prone and hard to keep consistent as the cluster evolves. The insight behind this patent is that a small set of declarative, SQL-level primitives can cover the common multi-region topologies while hiding most of that operational complexity.
Defining multi-region behavior with SQL abstractions
Rather than exposing replica placement knobs directly, the patent defines a compact vocabulary of SQL abstractions that compose to describe how a multi-region database should behave: regions, survival goals, and table localities. The idea is that users declare what they want (where data lives, what failures to tolerate, how tables tend to be accessed by workloads) and the system figures out the replica placement and configuration needed to make it happen and perform well.
Defining regions in a multi-region database: cluster vs. database
The patent distinguishes between:
Cluster regions: what the cluster can support (derived from where nodes actually run, via locality).
Database regions: what a database chooses to use, selected from the available cluster regions.
It also explicitly calls out that cluster regions available and database regions configured "may not be identical," since a database can choose a subset.
The first step in configuring a multi-region database is designating a primary region, which is always the first region added to a database. Additional database regions can then be added from the available cluster regions.
Survival goals: designing for zone and region failure
The patent defines two survivability goals that drive how voting replicas are placed:
SURVIVE ZONE FAILURE (zone survivability): tolerate at least one availability-zone failure.
SURVIVE REGION FAILURE (region survivability): tolerate at least one region failure.
It also notes practical constraints, like region survivability requiring at least three database regions.
Table locality: controlling where data lives and how it’s accessed
Table locality defines how data is distributed across regions in a multi-region database, determining where data is stored and how it is accessed by applications. The patent describes three table-locality configurations:
REGIONAL BY TABLE: the table is homed in a specific region, optimized for fast reads and writes from that region.
REGIONAL BY ROW: row-level homing, where each row has a "home region."
GLOBAL: optimized for fast reads from any region at the expense of slower writes.
One detail that engineers will appreciate: The patent specifies the exact SQL statements used to configure and inspect multi-region state (e.g., SHOW REGIONS FROM CLUSTER, SHOW REGIONS FROM DATABASE, SHOW SURVIVAL GOAL FROM DATABASE, plus the locality keywords themselves).
How these abstractions work in CockroachDB
These abstractions are the entry point for all multi-region configuration in CockroachDB. When you run ALTER DATABASE ... SET PRIMARY REGION, ALTER DATABASE ... SURVIVE ZONE FAILURE, or ALTER TABLE ... SET LOCALITY, you're using the vocabulary this patent defines. Every multi-region feature, including the placement controls and locality-aware optimizations described in the two follow-on patents, builds on this foundation.
The Multi-Region Overview doc is the best single place to see how these abstractions map to product features, covering cluster/database regions, survival goals, and table localities. The table localities page is the best deep dive on the three locality modes.
Controlling data placement and residency in multi-region databases (US Patent 12,499,127)
Why replica placement control matters in distributed systems
Multi-region database deployments aren't static. Even after you pick a topology and configure a database, a real system is constantly making decisions such as:
placing initial replicas
rebalancing for load
replacing replicas after failures
If those decisions aren't guided by higher-level intent, the cluster can drift away from your expectations. Worse, a failure can cause replica replacement to land somewhere "technically correct," but operationally surprising, potentially hurting latency, increasing cost, or violating where you intend data to reside.
Data domiciling and data residency: controlling where data lives
This patent is about making multi-region replica placement easier to reason about, by giving users higher-level placement primitives and then ensuring the system continues to respect that intent as the cluster evolves.
A key theme is data domiciling (or data residency): expressing a clear boundary around where replicas are allowed to live. The patent introduces super regions and restricted replica placement as a way to group regions and constrain replica placement within that group, keeping placement aligned with operational or compliance boundaries rather than letting it drift across an entire global footprint.
Managing failover with secondary regions
A second theme is being deliberate about behavior under failure. The patent describes a secondary region concept: an explicit, preferred region to use for placement and recovery behavior when a primary region fails, rather than leaving failover outcomes entirely to opportunistic rebalancing decisions.
Fine-tuning placement with zone configuration extensions
Finally, the patent recognizes that not every workload fits a single default policy. It describes zone configuration extensions, which are a way to customize and fine-tune the system's multi-region placement behavior without abandoning the safety and simplicity of the higher-level abstractions.
How CockroachDB enforces placement and residency policies
The patent's placement controls show up most clearly in the features we built to make data domiciling practical in CockroachDB. If your goal is "keep this data within a specific set of regions," you typically want two things:
a way to define the boundary of where the data is allowed to live; and
a way to avoid maintaining an unnecessary replica footprint outside that boundary
In CockroachDB, those concepts map naturally to super regions, as described by the data domiciling tutorial. (You can also jump straight to the explanation of super regions in the multi-region overview.)
Another important part of the patent's story is being intentional about failover behavior. Failures do more than test availability: They can shift leaseholders and replica placement, which can change both latency and where the system places data during recovery. That's where secondary regions fit in: They let you express a preferred "landing spot" for placement and recovery behavior during disruption.
Finally, when you need to go beyond the defaults, the supported way to fine-tune the configuration without abandoning the high-level abstractions is Zone Config Extensions. They're designed to extend the high-level multi-region SQL abstractions, so you can add constraints and preferences without taking on the full complexity of managing raw zone configurations yourself.
Locality-aware query optimization for low-latency performance (US Patent 12,488,000)
Why cross-region queries should be avoided
Locality-aware query optimization is the process of choosing query plans based on geographic location to reduce cross-region data movement and latency.
The optimizer is one of the most performance-critical parts of any database. It makes important decisions such as:
which indexes to use
where joins happen
how much work gets pushed down to remote nodes
In a single region (or single datacenter), the optimizer's cost model (CPU, I/O, cardinality, and network) is typically a reasonable proxy for wall-clock performance, so the lowest-cost plan tends to perform best in practice.
In a multi-region environment, network latency is locality-dependent. If a plan includes cross-region exchanges, those exchanges can become the primary driver of end-to-end latency. In practice, cross-region queries can significantly increase latency, which makes locality-aware execution critical for maintaining consistent application performance. A plan that looks fine to a traditional cost model can become painfully slow once it starts moving data across an inter-region link.
What locality-aware query optimization does
The patent describes a locality-aware approach where the database produces multiple candidate query plans and then chooses among them using a cost model that explicitly incorporates cross-region latency. The idea is straightforward but powerful: If WAN latency is a first-class cost input, the optimizer can reliably prefer plans that keep work local whenever possible.
Reducing cross-region data movement with region-aware planning
The patent goes further than "just add latency." It describes a cost model that can combine latency, network/bandwidth cost, and compute cost, so that the database can make nuanced decisions instead of applying a single heuristic.
It also describes region-aware plan transformations that expand the set of candidate plans the optimizer considers, enabling patterns that avoid unnecessary cross-region shuffles. One example is a "local-first" search strategy that tries to satisfy a query from the local region and only consults remote regions if needed. Another example describes transforming a cross-region join into a union of per-region joins when the partitioning column aligns, so most join work happens inside a single region.
Enforcing local execution with strict query controls
Another important facet of the patent is giving users a way to express when they want to avoid cross-region execution altogether. It describes an "Enforce Home Database Region" capability: When the enforce_home_region session setting is enabled, the system will only return results that it can satisfy entirely within the gateway node's region. If the optimizer can tell at planning time that the query necessarily requires remote data, it errors immediately; otherwise the execution engine may try a local-first strategy and error at runtime if completing the query would require consulting other regions (for example, when a LIMIT cannot be fully satisfied locally). This is effectively a mode that says, "If this can't be satisfied locally, don't silently turn it into a WAN query."
How CockroachDB optimizes queries for locality
At a high level, CockroachDB's locality-aware behavior shows up in two places:
locality-optimized execution patterns that try to keep common queries local when they can
an optional strict mode (enforce_home_region) that refuses to widen a query into cross-region execution
Both of these build on the same foundation: table localities, the SQL-level abstractions that let you describe how data is distributed across regions. The locality that matters most for these optimizations is REGIONAL BY ROW, where each row is assigned a home region and the table's indexes are partitioned by region. That structure is what enables the optimizer and execution engine to keep work close to the gateway region in many cases.
The most concrete locality-aware behavior users can observe today is what we describe as locality-optimized search. For certain queries against REGIONAL BY ROW tables, the database can often probe the local region first. For example, point lookups (selecting data by a unique key that identifies a row) and many queries with a LIMIT can use this optimization. If the query can be satisfied entirely from the local region (because the matching row is local, or enough rows are found locally to satisfy the limit), the engine can return results without involving other regions. If not, the normal behavior is to widen the search and consult other regions as needed for correctness. That "local-first, widen-if-required" pattern is one of the main ways REGIONAL BY ROW delivers low-latency access for workloads where rows tend to be accessed primarily from their home region.
The companion to locality-optimized search is the enforce_home_region session setting. While locality-optimized search will widen to other regions when correctness requires it, enforce_home_region draws a hard line: A query either completes using only local data, or it errors. This gives users an explicit way to prevent queries from silently becoming cross-region operations.
Finally, for a candid view of what's still evolving beyond today's locality-optimized behaviors, the public issue "make the optimizer distribution aware" is a good window into longer-term work on incorporating locality more deeply into the cost model and plan selection.
How these capabilities form a multi-region database architecture
These patents are easiest to understand as a layered system.
The multi-region SQL abstractions patent defines the user-facing vocabulary: cluster and database regions, survivability goals, and table localities.
On top of that foundation, the replica-placement patent focuses on keeping placement aligned with intent as the cluster evolves (including domiciling constraints and controlled behavior under failure).
Then the locality-aware optimization patent makes the query engine more geography-aware, so it can take advantage of those placement decisions instead of accidentally turning a local query into a cross-region query.
Together, they form a multi-region database architecture that aligns data placement, failure handling, and query execution with application intent. That helps organizations deliver consistent user experiences globally, while meeting regulatory requirements and maintaining availability during regional disruptions.
Applying multi-region design patterns in practice
If you want to try the ideas hands-on, start with the Low Latency Reads and Writes in a Multi-Region Cluster demo. It's the fastest way to see how topology choices show up in the latency that your application experiences.
From there, pick a single dataset and make the locality decision explicit: Is it truly global, is it regional by table, or do you want row-level locality with REGIONAL BY ROW? The table localities docs and the REGIONAL BY ROW blog post are good companion references as you experiment.
If you then find yourself asking, "How do I nudge or constrain what happens next?" there are two natural directions. For placement behavior, zone config extensions are the supported way to customize beyond the defaults. For query behavior, the optimizer docs explain how to influence whether certain queries stay within a single region.
If your workload has read paths that can tolerate slightly historical data, follower reads are another important tool in the multi-region toolbox.
The research behind multi-region SQL abstractions
If you want the research lens on the multi-region abstractions, we wrote up the SIGMOD 2022 paper and a related VLDB demo paper (with blog summaries). These papers focus on the foundational abstractions described in the first patent, and are a good complement to the product docs because they explain the design goals, tradeoffs, and principles behind regions, survival goals, and table localities.
What's next for multi-region query planning and placement
Multi-region query planning is still an active area of development, especially around latency-aware costing and additional region-aware plan transformations. Some of the ideas in the locality-aware optimization patent are still being iterated on, and the public issue #47226 is a good way to see the direction of travel.
Super regions for CockroachDB are also still in preview today; we're actively improving them and expect to GA the feature soon.
From resilience to region-aware database systems
What I like about these three patents is that they describe a coherent approach to multi-region that matches how engineers actually reason about systems:
Start with a small set of primitives (regions, survivability goals, and table localities)
Then preserve intent as the system adapts
Finally, make query planning respect geography rather than treating it as an afterthought.
That's the difference between "it runs across regions" and "it works the way you intended."
Try CockroachDB Today
Spin up your first CockroachDB Cloud cluster in minutes. Start with $400 in free credits. Or get a free 30-day trial of CockroachDB Enterprise on self-hosted environments.
Rebecca Taft is Director, Engineering at Cockroach Labs, leading the SQL Queries and Specialized Indexing teams. Notable projects include helping to build the cost-based query optimizer from scratch, and adding support for features such as geospatial indexing and locality-optimized search in multi-region clusters.
