←back to thread

Why does everyone run ancient Postgres versions?

(neon.tech)
264 points davidgomes | 7 comments | 17 Oct 24 21:23 UTC | HN request time: 0.001s | source | bottom
Show context
justin_oaks ◴[18 Oct 24 00:36 UTC] No.41875268[source]▶
My upgrade policy for everything:

Significant security vulnerability? Upgrade

Feature you need? Upgrade

All other reasons: Don't upgrade.

Upgrading takes effort and it is risky. The benefits must be worth the risks.

replies(5): >>41875370 #>>41875465 #>>41876163 #>>41876254 #>>41876707 #
1. occz ◴[18 Oct 24 06:00 UTC] No.41876707[source]▶
Upgrading when multiple versions behind is significantly more risky than doing it when the update is relatively fresh.

Additionally, actions done frequently are less risky than actions done rarely, since you develop skills in performing that action as an organization - see high deployment frequency as a strategy of managing deployment risk.

This adds up to continuous upgrading being the least risky option in aggregate.

replies(2): >>41877368 #>>41880107 #
2. kortilla ◴[18 Oct 24 08:20 UTC] No.41877368[source]▶
Not if software regressions are the main concern.
3. ttfkam ◴[18 Oct 24 15:06 UTC] No.41880107[source]▶
Upgrading from v11 to v16 is not materially different in Postgres from v14 to v16. Same tools. Same strategies.
replies(1): >>41880280 #
4. enraged_camel ◴[18 Oct 24 15:24 UTC] No.41880280[source]▶
We are planning to upgrade from 11 to 17 soon. Even thinking about it is giving me ulcers. Our infra provider said we actually need to upgrade to 13 first, and then to 17. They did not provide a reason.
replies(2): >>41880673 #>>41895330 #
5. Tostino ◴[18 Oct 24 16:04 UTC] No.41880673{3}[source]▶
I went through a postgres 10 > 16 upgrade recently. What made it easier was just doing a test run of the upgrade process.

Did a restore to a stage environment, worked on my upgrade scripts until I was happy (deployed to VMs with ansible, so manual work to write the upgradeprocessfor me), restored again and ran the upgrade process fresh, and then tested my application, backup scripts, restores, etc. Had everything working entirely smoothly multiple times before pulling the trigger in production.

No stress at all when we did it in prod.

replies(1): >>41880884 #
6. ttfkam ◴[18 Oct 24 16:23 UTC] No.41880884{4}[source]▶
Yep, that was our strategy as well: just keep iterating until the script run cleanly from start to finish without errors.
7. fillest ◴[20 Oct 24 13:46 UTC] No.41895330{3}[source]▶
A personal warning about 17.0 if you use streaming replication: secondary replica leaks memory quite actively. 16.4 is OK.