Database Upgrades

Minor versions carry security and bug fixes and are usually a restart. Major versions change on-disk formats and behaviour, and are a project. Treat them differently.

Minor version upgrades

Usually: install the new binaries, restart, done. Still worth doing deliberately:

• Read the release notes for behaviour changes. "Minor" occasionally includes a default change.
• Upgrade a replica first and observe it under real traffic before touching the primary.
• Have the previous package version available so a rollback is a reinstall rather than a restore.
• Schedule them. Deferring minor upgrades accumulates a backlog that eventually forces a large, risky jump.

Rolling Upgrades

The pattern that avoids downtime for a replicated cluster:

1. Verify the cluster is healthy and fully replicated.
2. Upgrade one replica; restart; confirm it rejoins and replication catches up.
3. Repeat for each remaining replica, one at a time.
4. Perform a planned switchover to an upgraded replica.
5. Upgrade the former primary and let it rejoin as a replica.

Before:  primary(v16)  replica-a(v16)  replica-b(v16)
Step 2:  primary(v16)  replica-a(v17)  replica-b(v16)
Step 3:  primary(v16)  replica-a(v17)  replica-b(v17)
Step 4:  replica-a(v17) promoted; old primary demoted
Step 5:  primary(v17)  replica-a(v17)  replica-b(v17)

For consensus-based clusters — CockroachDB, YugabyteDB, MongoDB, Elasticsearch — the same shape applies with a critical addition: finalisation. Until the upgrade is finalised, the cluster can usually be rolled back; afterwards it cannot. Wait for a full business cycle before finalising.

Testing before production

• Restore a production backup into a staging environment and upgrade that. This tests your data, not a synthetic dataset.
• Run the application's test suite and its slowest queries against the upgraded copy, comparing query plans. Optimiser changes between major versions can change plans in both directions.
• Record how long the upgrade took on production-sized data.

Rollback

Write the rollback down before starting, and be honest about what it is:

• Minor upgrade — reinstall the previous version and restart. Cheap.
• Major upgrade, before any writes — switch back to the untouched old cluster.
• Major upgrade, after writes — restore from backup and lose the writes, or replicate back if the engine allows it. Expensive, and the reason to keep the old cluster intact.

Version support

Track end-of-life dates for the versions you run. An unsupported version stops receiving security patches, and an emergency upgrade under an active vulnerability is far riskier than a scheduled one. Put the EOL dates in the same calendar as your certificate expiries.