PostgreSQL 14 ends November 12: test the upgrade first

What happens to PostgreSQL 14 on November 12?

The PostgreSQL project supports each major version for five years. Version 14 first shipped on September 30, 2021, and its final release is listed for November 12, 2026. After that date the project publishes no more bug or security fixes for it.

A version 14 server keeps running on November 13 exactly as it did the day before. What stops is the stream of fixes. The next security problem found in shared code will be fixed in 15 through 18, and 14 will stay exposed.

If you are choosing a target, the dates point to 18. Version 15 is supported until November 11, 2027, so it buys one year. Version 18 is supported until November 14, 2030. Upgrading to 18 is one project either way, and you will not have to repeat it next autumn.

Version 19 arrives a week after 14 loses support. Its first release candidate came out on October 15, and the project plans general availability for November 19. A major version that is days old is a poor target for a deadline upgrade. Version 18 has had a year of fixes. Move to 18 now and treat 19 as a later, unhurried project.

Which changes between 14 and 18 can break an application?

Jumping from 14 to 18 means reading the migration notes for 15, 16, 17 and 18. Many entries cover monitoring views, replication and backup tooling. These are the ones to check first in application code and schemas:

• New databases no longer let everyone create objects in the public schema (version 15). An upgraded or restored database keeps its old permissions, but a database created fresh on 15 or later does not. Migrations that run as a role that does not own the database can fail with a permission error, and only in new environments.
• Numbers glued to text are now an error (version 15). Query text such as 123abc used to be read as 123 followed by abc. Generated SQL with a missing space now fails instead of quietly meaning something else.
• Fractional years in intervals round to the nearest month (version 15). The release notes give the example of 1.99 years, which now becomes 2 years instead of 1 year 11 months. Check anywhere the app builds intervals from text or user input.
• random() returns different values for the same seed (version 15). Tests that seed random() and expect a known sequence of values will see new numbers.
• Views can no longer be built by hand from ON SELECT rules (version 16). Old schemas that created a table and then attached a select rule to turn it into a view need to use CREATE VIEW instead.
• Maintenance commands run functions with a safe search_path (version 17). A function used by an expression index or a materialized view that refers to another schema without naming it can now fail during REINDEX, ANALYZE or REFRESH MATERIALIZED VIEW.
• The word ago must come last in an interval (version 17). An interval string with ago in the middle is now rejected.
• MD5 passwords are deprecated (version 18). Setting one now prints a warning, and support will be removed in a later major version. Plan the move to SCRAM while you are already changing things.
• Full text search and trigram results can differ on ICU or builtin collation (version 18). Clusters that use ICU or the builtin provider may see different full text and trigram behaviour. The notes recommend reindexing those indexes after pg_upgrade.

Why does a passing test suite not prove the upgrade is safe?

Most items above depend on something your test database does not have. Test fixtures are small, recent and clean. Production holds the interval string someone typed in 2019, the reporting function written before anyone set a search_path, and the materialized view that only refreshes at night.

A database built fresh on 18 also differs from one upgraded from 14. Schema permissions follow the upgrade method. The checksum setting is chosen when the cluster is created, and changing it later means downtime. Since 18, new clusters have checksums on by default, and pg_upgrade needs the old and new clusters to match. A fresh install can pass every test while the real upgrade path fails at the first step.

Ask whether the queries production runs return the same rows and the same errors on an upgraded copy of production's data.

How do you test the upgrade against what the app really does?

Most of these steps use only what ships with PostgreSQL. The comparison in step 3 is a small script you write.

1. Upgrade a copy the same way you will upgrade production. If production will go through pg_upgrade, rehearse with pg_upgrade. If you will dump and restore, rehearse that. Time it, because the timing is your maintenance window.
2. Collect the queries production really runs. The pg_stat_statements extension shows which query shapes run most, but it stores placeholders instead of values. For statements you can run again, log them for a short, quiet period and keep the log.
3. Run those queries against both versions and compare. Compare rows, row order where the app depends on it, and error codes. A query that errored on 14 and succeeds on 18 deserves as much attention as the reverse.
4. Run the maintenance commands by hand. REINDEX, ANALYZE and REFRESH MATERIALIZED VIEW on the upgraded copy will surface the search_path change before the nightly job does.
5. Search the code for the small things. Look for setseed, interval strings built in code, md5 in your authentication config, and dashboards that read blk_read_time or blk_write_time from pg_stat_statements, which 17 renamed.
6. Check the plans of your slowest important queries. A different plan on the new version can turn a fast page into a slow one without any error at all. On 18, pg_upgrade keeps planner statistics but not extended statistics, so run ANALYZE before you judge any plan.

What about the customer data in that copy?

A rehearsal copy of production is still production data. It holds names, emails, password hashes and session tokens, and it now lives somewhere with looser access than the real thing. Keep it inside the same security boundary as production, delete it when the rehearsal is done, and do not hand it around as a convenience.

If the copy has to leave that boundary, shrink it and scrub it first. Nearly every change listed above depends on the shape of the data and the age of the schema objects, not on the size of the tables. A copy that keeps the rows your important queries touch, with secrets replaced, will catch most of what a full copy would. Plan and timing checks are the exception. Those still need production sized tables.

What if you cannot finish by November 12?

Then plan a short gap instead of a rushed weekend cut over. During the gap, a newly found security problem will not be fixed in 14, and that exposure grows each month. Keep the gap short, and rehearse anyway.

If your database is run by a hosting provider, read their own schedule today. Providers set their own retirement dates, and some may force an upgrade at that point, so check yours.

Questions people ask

Does PostgreSQL 14 stop working after November 12, 2026?

No. The server keeps running. The project stops releasing bug and security fixes for version 14, so new problems found after that date stay unfixed in 14.

Should I upgrade from PostgreSQL 14 to 15 or to 18?

To 18, unless something you depend on does not support it yet. Version 15 loses support on November 11, 2027, while 18 is supported until November 14, 2030.

Should I wait for PostgreSQL 19 instead?

Not if you are on 14. Version 19 is planned for November 19, 2026, after 14's support ends, and it will not have had any point releases yet. Upgrade to 18 first.

Can I skip versions when upgrading PostgreSQL?

Yes. Both pg_upgrade and dump and restore can go from 14 directly to 18. Read the migration notes for every version you skip, because each one lists its own changes.