YugabyteDB Multi-Region Topologies: Synchronous Replication, xCluster or Read Replicas

YugabyteDB gives architects several ways to run across regions: one universe replicated synchronously across regions, rows pinned to regions with geo-partitioning, two universes linked by asynchronous xCluster replication, or read replicas in remote regions. Each answers a different question. Choosing the wrong one usually shows up later, as write latency nobody budgeted for or data that is missing after a failover.

This article explains what each pattern does according to the official documentation, what it costs, and how we decide between them. It is about self-managed open-source YugabyteDB. Operations through YugabyteDB Anywhere or YugabyteDB Aeon, which are YugabyteDB, Inc.’s commercial products, follow those products’ own documentation and terms.

The four patterns at a glance

The multi-region deployments overview summarises the main options. In plain terms:

Pattern	Replication between regions	Where writes go	What reads see	Effect of losing a region
Synchronous multi-region universe	Synchronous (Raft)	Any region; each write waits for a majority of replicas	Transactional, consistent	Universe keeps serving from remaining regions if placement allows
Row-level geo-partitioning	Synchronous inside each partition’s placement	The region that holds the row’s partition	Transactional, consistent	Partitions placed in the lost region can become unavailable
xCluster (two universes)	Asynchronous	Source universe (target is read-only in transactional mode)	Target reads lag behind the source	Writes not yet replicated are lost on failover
Read replicas	Asynchronous, one way	Primary cluster only	Timeline consistent, possibly slightly stale	Reads fall back to another replica or the primary

The patterns can be combined. A synchronous universe can carry read replicas, for example. The decision is which properties you need for which data.

Synchronous replication across three or more regions

The synchronous multi-region page describes the default pattern. With a replication factor of 3 spread across three regions, the universe continues to serve requests if one region fails, and tablet leadership moves to the remaining regions automatically. All writes are replicated synchronously and transactions are globally consistent.

The xCluster architecture page states the cost plainly. To tolerate the failure of f fault domains, you need at least 2f + 1 of them, so surviving the loss of one region needs three regions. And because a write must reach a majority of replicas before it is acknowledged, every write includes a round trip between regions.

The documentation describes two levers that reduce the impact:

• Preferred regions. Pinning tablet leaders to the region where most traffic originates keeps reads and leadership local. Followers stay in the other regions, so placement and fault tolerance do not change.
• Follower reads. Reads that can accept some staleness can be served by a nearby follower instead of the leader, with a configurable maximum staleness.

Client routing matters as well. The page shows the YugabyteDB smart driver configured with topology keys so that applications connect to the closest region. We treat leader placement, follower reads and driver settings as one design, because changing one changes how the others behave after a failure.

Geo-partitioning for data residency

The row-level geo-partitioning page describes how to pin rows to locations. You create tablespaces with a replica placement per region, then create a list-partitioned table whose partitions use those tablespaces. Each row lands in the partition for its region, and that partition can be replicated across zones in the region or across nearby regions.

This pattern suits two needs: keeping personal data inside a jurisdiction, and keeping reads and writes close to the users who own the data. It keeps transactional semantics and propagates schema changes across regions. The trade-off appears in failure planning. If all replicas of a partition sit in one region and that region is lost, the overview page notes that partial unavailability is possible. Queries that touch partitions in several regions also pay cross-region round trips.

Residency is a legal question as well as a technical one. The database can place data; it cannot decide which rules apply. We agree the residency model with the data owner and legal team before designing partitions, and we document which global tables and indexes still span regions.

xCluster: two universes, asynchronous replication

xCluster replicates write-ahead log records asynchronously from a source universe to a target universe. The architecture page lists its benefits: lower write latency because there is no cross-region consensus, only two data centres needed, and independent universes that can each run on their own. It also lists the drawbacks: data not yet replicated is lost if the source fails, and reads on the target can be stale.

For YSQL, the documentation prefers transactional mode. The target is read-only, and reads run as of the xCluster safe time, so transactions from the source become visible atomically and in commit order. The transactional xCluster deployment page lists three setup modes:

Mode	Schema changes	Status on the research date
Automatic	Replicated automatically	GA in v2025.2.1; recommended for new deployments
Semi-automatic	Applied on both sides, fewer steps	GA in v2024.2.0; deprecated in v2025.2.1
Manual	Applied on both sides, configuration updated by hand	GA in v2.18.1; deprecated in v2025.1

The same page distinguishes two operations. A switchover is planned: replication is reversed after the standby catches up, so no data is lost. A failover is unplanned. The failover procedure pauses replication, reads the safe time, and uses point-in-time recovery to restore the standby to that time, discarding partially replicated transactions. The documentation warns that failover can lose committed data and should only be done when the primary will not recover soon and the loss is acceptable.

Several limits shape the design. Users, roles and tablespaces are not replicated and must be managed on both sides. Backups should be taken on the source, because backups of the target are not transactionally consistent. Change data capture is supported on the source only. Broadcast, consolidation, daisy-chain and star topologies are listed as unsupported. On Kubernetes, the two universes must be able to reach each other’s pods directly.

Bidirectional xCluster: use with great care

Two unidirectional flows in opposite directions give an active-active setup where both universes accept writes. This runs in non-transactional mode with last-writer-wins conflict handling. The architecture page lists the consequences: concurrent writes to the same key can produce inconsistent data or corrupt indexes, unique and foreign key constraints cannot be enforced across universes, sequences are not replicated, and triggers fire only on the universe where the write happened. The page states that this mode is not recommended for YSQL deployments.

We only consider it when the application already partitions writes so that each key has a single home universe, and when the team accepts that conflicts are resolved by timestamp rather than by constraints.

Read replicas for remote reads

The read replicas architecture page describes read replicas as observer nodes. They receive data asynchronously, do not take part in Raft consensus and do not add to write latency. Because they do not vote, a read replica cluster can have any replication factor, including an even number. Schema changes apply to them automatically, and writes sent to a read replica are redirected to the primary.

The read replicas guide notes that reads may return slightly stale data, with a configurable staleness bound, and that applications fall back to the next closest replica or the leader if a read replica region fails. Read replicas do not provide a second writable copy for disaster recovery. They are a read-scaling tool.

How we choose

We start from the business requirements, not the topology diagram. These questions usually decide the pattern:

1. Must committed writes survive the loss of a region without any loss? If yes, you need synchronous replication across at least three regions, or across nearby regions for each geo-partition.
2. Can the business accept losing the most recent writes in a regional disaster, in exchange for local write latency and only two sites? If yes, transactional xCluster in automatic mode is the usual candidate.
3. Must some data stay in a specific jurisdiction? If yes, geo-partitioning, with an explicit plan for what happens when that region is unavailable.
4. Do remote users mainly read, and can they accept slightly older data? If yes, add read replicas or follower reads rather than more voting replicas.
5. Does the team have the skills and runbooks to operate two universes? xCluster doubles the number of universes to upgrade, monitor and back up.

Recovery objectives are agreed per workload and then proven. We do not quote recovery figures in advance, because they depend on the network between sites, the workload and the procedure. Our platform reliability practice covers how we run those tests.

Test the topology before you trust it

• Stop a whole region in a synchronous universe under load, and record how leadership moves and how clients reconnect.
• Rehearse an xCluster switchover and an unplanned failover, including the point-in-time restore to the safe time and the application’s connection switch.
• Measure replication lag on the real network during peak load, and alert on it.
• Check that users, roles and tablespaces exist on both universes before you need the standby.
• Plan upgrades in the order the documentation requires: for unidirectional xCluster, the upgrade guide says to upgrade and finalize the target before the source.

How Bassirah can help

Bassirah designs, deploys and tests multi-region topologies for self-managed YugabyteDB as independent engineering, through our consulting and architecture service and our YugabyteDB practice. Bassirah is not a YugabyteDB, Inc. partner and does not provide vendor support or escalation; see our open-source support model. If you need YugabyteDB Anywhere, YugabyteDB Aeon or vendor support, that is contracted with YugabyteDB, Inc.