Testing a PostgreSQL Multi-AZ DB Cluster from 14 to 18 upgrade scenarios

These results are a synthetic benchmark and are not representative of any specific production workload. Use them to compare the two deployment types under identical conditions, not to predict your application's actual throughput or latency, or downtime duration.

Tested upgrade fresh RDS Multi-AZ DB cluster (PostgreSQL, 3 nodes, db.r8gd.xlarge, io2 storage) and walked it all the way from PostgreSQL 14.18 to 18.4 — alternating one small minor bump inside each major with a major jump: 14 → 15 → 16 → 17 → 18. Nine upgrades, one cluster, no rebuilds.

Upgrade scenarios tested

14.18 →(minor) 14.19 →(MAJOR) 15.14 →(minor) 15.15 →(MAJOR) 16.11
      →(minor) 16.12 →(MAJOR) 17.8 →(minor) 17.9 →(MAJOR) 18.3 →(minor) 18.4

One gotcha: a major upgrade won't let you land on an old minor unless you're already on an old minor. Start from the newest 14 (14.23) and RDS only offers you 15.18. Start low (14.18/14.19) and you can land on 15.14, leaving room to test a 15 minor. So I deliberately entered each major early.

Maintenance window ≠ downtime

The single most important thing I got wrong in my first pass: the big wall-clock numbers are mostly maintenance window, not downtime. Each upgrade brackets the real work with automated pre/post snapshots — and during those snapshots the database is up and serving. Snapshots belong in your change window, but they are not an outage. So I re-measured downtime strictly from DB instance shutdown → DB instance restarted events, per node.

Minor upgrades: a rolling near-non-event

A minor upgrade is rolling: upgrade the readers one at a time, failover to an upgraded reader, then upgrade the old writer last. Because the reboots are staggered:

• Writes: interrupted only for the single failover — ~15–35s.
• Reads: zero outage. Each node blips ~31s, but never all at once, so the reader endpoint is always live. (Reader-1 and Reader-2 reboot at different times — I keep them separate, because averaging or summing them would hide the fact that the endpoint never actually goes dark.)
• Maintenance window: ~7–11 minutes (mostly snapshots).

Major upgrades: pay the piper (on writes)

A major upgrade is in-place with no failover. The writer is shut down and upgraded via pg_upgrade; the two readers are rebuilt near the end.

• Writer / writes: down for the in-place window — the core engine upgrade is ~6–6.7 min, and the writer node's total down window (it's also offline during the pre-upgrade snapshot) runs ~12.5–13.5 min.
• Readers / reads: here's the catch — unlike minors, both readers reboot together near the end (~50–63s each), so the reader endpoint has a ~50–60s read outage. Reader-1 and Reader-2 are reported separately, but their windows overlap, which is exactly why reads briefly drop.
• Maintenance window: ~15–16.5 minutes.

The hidden cost: snapshots between steps

The whole campaign took ~3.5 hours even though actual downtime summed to only a few minutes. Why? After every upgrade the cluster enters a mandatory backing-up state (DB up) and you can't start the next upgrade until it clears — 6–10 minutes each, nine times.

Takeaways

• Minor = almost free on availability: a ~15–35s write failover and zero read outage.
• Major = a real write window: ~6–13 min of write unavailability (no failover), plus a ~1-min read blip when both readers cycle. Reads otherwise survive.
• Don't count snapshots as downtime — count them as maintenance window; the DB is serving.
• Report each reader separately. With two readers, summing their downtime is misleading — the endpoint only actually drops when their windows overlap (which happens on majors, not minors).
• Enter each major on an early minor to keep testing minors as you climb.

All nine upgrades succeeded first try, 14 → 18, on the same cluster.