PostgreSQL 14 stops getting fixes on 12 November. Go to 18 now, or wait for 19?

The sentence from the wz-it upgrade guide that I would put in your planning doc: “For a comparable vulnerability after 12 November 2026, there would be no patch for PostgreSQL 14.” Today is 30 October. You have 13 days.

My recommendation: 18 now, unless you have a reason

The guide’s advice, and mine, is that PostgreSQL 18 is the target for most production systems. Version 19 reaches GA on 19 November, a week after 14’s deadline, and I would not rush a database through a brand-new major release to beat a date. The released-minor argument is simple: 18 is already at 18.6, so its first rough edges have been fixed by other people.

None of this means 19 is a bad choice. If you have months, not days, and a good staging setup, waiting for 19.1 or later and going once is reasonable. If you are short on time, a second upgrade next year is cheaper than running an unsupported database.

The upgrade, in the order I would do it

Direct upgrades from 14 to 18 are supported, according to the guide, so you do not have to hop through 15, 16 and 17. The tool is pg_upgrade. I checked the 18.6 binary on my machine, and it offers --jobs, --clone, --copy-file-range, --swap and --no-statistics.

1. Take a backup and prove you can restore it. A rollback plan that has never been exercised is a hope.
2. Install 18 beside 14 and run pg_upgrade --check with both data directories. Fix what it reports.
3. Rehearse the real upgrade on a copy of production data, with the same flags, and time it.
4. Pick the transfer mode. --clone or --copy-file-range where your filesystem supports them; --swap is the fastest.
5. Cut over in a window, run ANALYZE if you skipped statistics, and keep the old cluster until you are confident.

Things the guide flags that people forget

• pg_upgrade in 18 transfers most planner statistics. The guide notes extended statistics from CREATE STATISTICS are not transferred, so recreate or re-analyse those.
• Data checksums must match between old and new clusters. 18 enables them by default, so decide before you initialise.
• MD5 passwords are deprecated. Converting to SCRAM-SHA-256 during the move is a good time.
• Tables without a primary key need an explicit replica identity if you use logical replication.
• Custom backup scripts that use the old exclusive backup mode need updating.

If you cannot make 12 November

Be honest about it and write down the risk. An unsupported database is not an emergency on day one: the danger is the first security fix you will not get. In the meantime restrict network access to it, keep your last 14.24 patched, and pick a date for the real upgrade this quarter. If you use a managed service, check what your provider promises after the community stops. I could not find that for any provider, so ask them.

Sources & Credits

• WZ-IT, “PostgreSQL 14 end of life: upgrade guide”: wz-it.com
• PostgreSQL Global Development Group, “PostgreSQL 19 RC 1 Released!” (GA date): postgresql.org

The decision table and runbook are our own work. The pg_upgrade flags were read from the 18.6 binary’s help; no 14 to 18 upgrade was performed here. Last verified 2026-10-30. Spotted a mistake? Tell us and we will correct it here with the date.