Manas Mishra
Résumé

Case study Datavio · Databases

Moving production Postgres across regions to double its capacity

Our database needed to grow, and its US region couldn't give it room. A cross-region read replica turned a risky migration into a short, planned cutover — and unlocked 2× server capacity.

Role
Planned & executed
Context
Datavio · production database
Platform
Azure Database for PostgreSQL Flexible Server
Technique
Cross-region read replica, then promotion
Server capacity after the move — a size the US region couldn't provision
2×
Dump-and-restore steps — the data streamed over via replication
0
Planned cutover window: freeze writes, promote, repoint
1
US region new region replication before after cutover postgres · primary capacity capped replica → primary scaled to 2× app services
The replica streams from the capped US primary until cutover. Then it's promoted to a standalone primary, the services are repointed, and the new server scales up.
TL;DR Our Azure Database for PostgreSQL Flexible Server lived in a US region that couldn't give us the capacity we needed. Instead of a dump-and-restore, I created a read replica in a region with headroom and let it stay in sync with production. The cutover was a short, planned window: pause writes, let the replica catch up, promote it to a standalone primary, repoint the services. On the new server we scaled to 2× the capacity the old region allowed.

01 · The problemScale up… denied

As the platform's load grew, the database became the constraint. The obvious fix — scale the server up — was blocked: the US region it lived in wouldn't let us grow it to the size we needed.

Waiting on regional capacity isn't a plan. And the classic alternative — dump the production database and restore it somewhere else — means a long outage and a nervous night.

02 · The intuitionA replica is a migration tool

Read replicas are usually pitched as a read-scaling feature. They're also the gentlest way to move a database. A replica in another region stays continuously caught up with production, so the "migration" shrinks to the few minutes it takes to promote it.

The data moves while the business keeps running. Only the cutover needs a maintenance window.

03 · The runbookSix steps, in a fixed order

  1. Create the replica. Spin up a read replica of the primary in a region with the capacity we needed.
  2. Let it catch up. Watch replication lag until the replica is consistently in step with the primary.
  3. Freeze writes. Open a short maintenance window and stop writes, so nothing lands on the old primary mid-switch.
  4. Promote. Once lag hits zero, promote the replica to a standalone read-write server.
  5. Repoint. Switch the services' connection settings to the new server and bring writes back.
  6. Scale up. With the new region's headroom, scale the server to 2× its previous capacity.

04 · ImplementationWhy this beats dump & restore

Dump & restore

The outage lasts as long as dumping and restoring the entire database. Any failure means starting over.

Replica promotion

Data syncs ahead of time while production runs. The outage is just the cutover.

Cutover discipline

The replica does the heavy lifting; the cutover is about ordering. Writes stop before promotion, promotion waits for zero lag, and services only come back once they point at the new primary — so no write can land on the wrong server.

One variable at a time

Moving first and scaling second kept the migration boring: the move changed where the database lived, and only once it was settled did we change how big it was.

05 · ResultsRoom to grow

  • 2× server capacity — a size the original US region wouldn't provision.
  • The data moved through continuous replication; no dump-and-restore.
  • Downtime was limited to a single planned cutover window.

06 · LessonsWhat I'd tell my past self

  • Cloud capacity is regional and finite. Treat "can we scale up here?" as a question to answer before you need the answer.
  • Replicas aren't just for reads — they're the lowest-drama way to move a database.
  • Make cutovers boring: a fixed order of steps and a clear go/no-go on replication lag.

Planning a database move or hitting capacity walls? Happy to swap notes.