A short guide to multi-region Postgres

Multi-region Postgres is one of the most expensive distributed-systems decisions a team can make, and one of the most commonly made for the wrong reasons. If you are considering it, slow down. The default — a single primary in a single region with healthy read replicas — is sufficient for the overwhelming majority of workloads.

When you actually need multi-region

There are three reasons multi-region is genuinely the right call:

Latency-bound reads from a global user base. You serve users on multiple continents and your read latency budget is incompatible with a transatlantic round trip.

Regulatory data residency. Different users' data must live in different jurisdictions and never cross borders.

Hard disaster recovery requirements. Your business cannot tolerate the recovery time of a single-region outage with cross-region backups.

If none of these apply, you do not need multi-region. Many teams adopt it because it sounds responsible. It is not — it is a tax you pay on every release and every incident, for years.

The three patterns

Read replicas in other regions. The simplest case. Your primary stays in one region; replicas in other regions serve reads. Writes still pay the cross-region tax. Works well when read traffic dominates and write latency is tolerable.

Active-active with conflict resolution. Each region can accept writes. Conflicts are resolved by last-write-wins or by application-level merge logic. Powerful and dangerous — most teams underestimate how often conflicts happen in their data and how complex the merge logic gets.

Sharded by region. Each user's data lives in one region; the application routes requests to the correct region. Conceptually clean, operationally complex, and the only pattern that genuinely satisfies hard data-residency requirements.

The operational reality

Whichever pattern you pick, the operational surface area roughly triples. Schema migrations have to be coordinated across regions. Backups and DR drills now span regions. Monitoring has to surface region-by-region. On-call rotations have to handle regional outages.

The honest recommendation

Start with read replicas. They cover most of the latency cases and add minimal complexity. Move to active-active only when you have concrete evidence the read-replica pattern is insufficient — usually because writes from a remote region are too slow.

If the answer is "we just need to be in three regions because it sounds professional", the answer is no. Spend the engineering time on something that moves the business.