PostgreSQL 14 end of life: what to check

PostgreSQL 14 gets its final update this Thursday, 12 November. After that, the PostgreSQL project stops fixing it. No more bug fixes, no more security fixes.

Nothing breaks on Friday. Your database will carry on exactly as before. But if your website or app runs on PostgreSQL 14, this is the week to find out, and to put an upgrade in the diary.

What's happening

The PostgreSQL project supports each major version for five years. Its versioning policy says that after that, "a final minor version will be released" and the software is unsupported. Version 14 came out on 30 September 2021, and its final release date on that page is 12 November 2026.

There's no drama here. It's a published date, and it's been on that page for years. It's just easy to miss when the database was set up by someone else and has quietly worked ever since.

Does it affect you?

The most likely way to have PostgreSQL 14 is Ubuntu 22.04. The postgresql package on Ubuntu's package list is version 14 on 22.04, 16 on 24.04 and 18 on 26.04. So if your server was built on 22.04 and nobody changed the default, it's probably 14.

To check, log in to the server and run:

psql --version

On Ubuntu and Debian, this one shows every database cluster on the box, with its version and whether it's running:

pg_lsclusters

If your app runs in Docker, look at the image in your docker-compose.yml or Dockerfile. Something like postgres:14 or postgres:14-alpine is the one to look for.

If you can't log in, ask your developer or host one question: "Which PostgreSQL version is our database on?" It's a fair question and should have a quick answer.

What end of life means on Ubuntu

This is the bit that's easy to get wrong in either direction.

On Ubuntu 22.04, postgresql-14 comes from the Main repository. Ubuntu's release cycle page says LTS releases get "CVE patches for packages in the Main repository". So you're not left completely on your own on Thursday.

But I wouldn't treat that as a reason to stay put. Once the PostgreSQL project stops publishing fixes for 14, anything Ubuntu ships has to be worked out separately, and I couldn't find anything public from Canonical saying how it will handle that. Ubuntu 22.04's own standard security maintenance ends in May 2027 as well. So you've got two clocks running, and both point the same way.

If your database is on Amazon RDS

AWS gives you a bit longer. Its RDS release calendar shows standard support for 14 ending on 28 February 2027.

After that, the database moves into what AWS calls Extended Support, and AWS's Extended Support charges page says the charges start the day after standard support ends. It's billed on top of what you pay now. If you're on RDS, put 1 March 2027 in the diary and plan to be upgraded before then. A surprise line on the AWS bill is not a fun way to find out.

What to do this week

1. Find out what you've got. Run the checks above on every server, and check any Docker setups. Write down the version for each one.

2. Check your backups actually restore. Before anyone touches a major version, you want a recent backup that you know works. Not just one that exists. Restore it somewhere and look at it.

3. Pick a target version. The current release is 18, supported until November 2030. If your app or one of its extensions hasn't been tested on 18 yet, 17 is fine too, supported until November 2029. Either gives you years.

4. Test the upgrade on a copy first. PostgreSQL's pg_upgrade tool moves your data to a new major version "without the data dump/restore typically required". On Ubuntu and Debian, pg_upgradecluster does the whole job for you, and adding -m upgrade makes it use pg_upgrade. Run it on a copy of the server, then run the app against the copy and click around.

5. Book a quiet hour for the real thing. The upgrade itself is often quick. The checking afterwards is what takes the time.

The app matters as much as the database

The database upgrade is usually the easy part. The harder question is whether the app on top of it still behaves. Old code sometimes leans on a behaviour, an extension or a driver version that's changed along the way.

If your app was written by a developer who's since moved on, and nobody's quite sure what it depends on, that's the bit to sort out first. The team at Dev Partners take on existing software and look after it month to month, upgrades included. They also wrote about the same problem with old PHP apps, and it's very much the same story with databases.

For the server side, this is what a fix-up project is for. I'll find out what version you're on, test the upgrade on a copy, do the real one at a quiet time, and tell you in plain English what changed.