Lesson 6 of 7

Blue/Green and Logical Replication Upgrades

Applies to PostgreSQL 13–17 Last reviewed May 2026 Grounded in source

The one thing to understand first

PostgreSQL’s on-disk format can change between major versions, so you cannot simply start a new binary on the old data directory. The traditional options each have downsides: pg_dump/restore is simple but slow and needs a long outage; pg_upgrade with hard links is fast but still requires stopping the database and is hard to roll back. Logical replication enables a blue/green upgrade with downtime measured in seconds.

Logical replication is version-agnostic — it ships row changes, not WAL bytes — so it lets a new-version “green” instance track an old-version “blue” until you flip traffic in seconds, with blue still intact as a fallback. That cross-version property is the entire reason near-zero-downtime major upgrades are possible.

The blue/green idea

Blue is your current production database. Green is a freshly built instance on the new major version. You replicate all changes from blue to green logically, let green catch up, validate it, then flip application traffic to green in one quick cutover. If anything is wrong, you flip back — blue was never touched destructively.

This is a Pro lesson

Get every Learning Pathway and cookbook recipe — grounded in PostgreSQL source code, with diagnostics, fixes, and prevention for each topic.

Continue this lesson to learn:

  • Why logical (not physical) replication
  • The procedure
  • Layer 3 — Watch it happen on your own database
  • Layer 4 — The levers this hands you
  • Layer 5 — What an Oracle DBA should expect vs what they get
  • Key takeaway
  • All 36 Learning Pathway lessons
  • 170+ cookbook recipes
  • Source-grounded diagnostics & fixes

Secure checkout Cancel anytime Source-grounded

Was this helpful?

← Back to 03 — Operations: Zero-Downtime Deployments