PostgreSQL 14 End of Life on 12 November 2026: Upgrading to 18 or 19

Running PostgreSQL 14? WZ-IT plans and carries out PostgreSQL major upgrades and then operates the database with monitoring, backups and restore tests, see PostgreSQL at WZ-IT and Managed Operations. Book a meeting

On 12 November 2026 the final minor release for PostgreSQL 14 will be published. After that, this major version receives no more bug or security fixes. The PostgreSQL Global Development Group stated this explicitly again in its announcement of 13 August 2026: anyone running PostgreSQL 14 in production should plan an upgrade to a supported version (release announcement).

At the same time, PostgreSQL 19 is about to be released, announced for October 2026. That reopens the question of the target version: PostgreSQL 18, available for a year, or the new version 19 straight away. This article shows the official support periods, compares the target versions and the three upgrade methods, and lists the incompatibilities that matter when moving from 14 to 18. All version information reflects October 2026.

Table of Contents

1. What the end of support for PostgreSQL 14 means
2. Support periods of all PostgreSQL versions
3. Target version: PostgreSQL 17, 18 or 19
4. PostgreSQL 19 before the release
5. Three upgrade methods compared
6. In-place upgrade from 14 to 18
7. Upgrading via logical replication
8. Incompatibilities between version 14 and 18
9. Pre-upgrade checklist
10. Our approach at WZ-IT
11. Further guides

What the end of support for PostgreSQL 14 means

PostgreSQL supports each major version for five years from its initial release. A final minor release follows, after which the version is end-of-life (Versioning Policy). PostgreSQL 14 was released on 30 September 2021; the final release is scheduled for 12 November 2026, the same date as the regular minor release in the release schedule.

Operation does not stop on the deadline. The risk lies in vulnerabilities disclosed afterwards. The release of 13 August 2026 shows how much accumulates in one quarter: it fixed 28 security vulnerabilities and more than 110 bugs. Among them was CVE-2026-16239, a type confusion in the cursor lifecycle that allows an authenticated database user to execute code as the operating system user running the database server (CVSS 8.8). It affected all versions from 14 to 18 and is fixed in 14.24. For a comparable vulnerability after 12 November 2026, there would be no patch for PostgreSQL 14.

For organisations within the scope of NIS2 or with ISO 27001 certification, unmaintained software also regularly turns up as an audit finding. How to track versions and vulnerabilities systematically is covered in the article on CVE monitoring for self-hosted software.

Distribution packages. Ubuntu 22.04 LTS ships version 14 in the postgresql package (packages.ubuntu.com). Whether and for how long a distributor backports fixes after upstream support ends is governed by the distributor's own lifecycle, not by the PostgreSQL community. Newer major versions for Debian and Ubuntu are available from the community repository apt.postgresql.org.

Support periods of all PostgreSQL versions

Source: PostgreSQL Versioning Policy, as of October 2026. Minor releases appear at least once per quarter; according to the release schedule, the next dates are 12 November 2026, 11 February 2027, 13 May 2027 and 12 August 2027. The community recommends always running the current minor release of the major version in use.

Upgrading from 14 to 15 or 16 means facing another major upgrade within one to two years. PostgreSQL 15 ends in November 2027, 16 in November 2028. That argues for moving to at least 17.

Target version: PostgreSQL 17, 18 or 19

PostgreSQL 18 is the obvious target for most systems that now have to move off 14. It has been available since September 2025, has six minor releases behind it and is supported until November 2030. It brings two concrete advantages for the upgrade itself (PostgreSQL 18 release announcement): pg_upgrade keeps most planner statistics, so the system reaches its usual query performance sooner after the switch, and the new --swap mode moves the data directories instead of copying or linking files. It also added a new asynchronous I/O subsystem, skip scan on multicolumn B-tree indexes, uuidv7() and OAuth authentication.

PostgreSQL 17 is an option when an application vendor or an extension has not yet certified PostgreSQL 18. With support until November 2029, there is sufficient distance to the next mandatory upgrade.

PostgreSQL 19 is announced for October 2026. For an upgrade that has to be completed by 12 November 2026, that is a tight window: only a few weeks would remain between release and deadline for testing, and extensions such as PostGIS or TimescaleDB typically need some time before matching packages are available. Anyone who has to replace 14 by the deadline therefore moves to 18 and schedules 19 as a later, regular upgrade.

PostgreSQL 19 before the release

As of late September 2026, the PostgreSQL 19 release notes do not list a release date yet. According to the Beta 4 announcement, a release candidate is planned for early October and general availability for October 2026 (Beta 4).

Source: PostgreSQL 19 release notes, as of Beta 4.

Reverted with Beta 4. Several features that were included in earlier betas and are mentioned in many previews are no longer part of PostgreSQL 19: SQL/PGQ for property graph queries, enabling and disabling data checksums online, temporal updates and deletes with FOR PORTION OF, ALTER TABLE ... MERGE PARTITIONS and SPLIT PARTITIONS, and the functions pg_get_role_ddl(), pg_get_tablespace_ddl() and pg_get_database_ddl(). The stated reasons are reliability and keeping the release date.

Incompatibilities in 19. The release notes include, among others: RADIUS authentication is removed, standard_conforming_strings can no longer be turned off, JIT is disabled by default, max_locks_per_transaction increases from 64 to 128, and the MULE_INTERNAL encoding is no longer supported. These items also reflect Beta 4 and may still change before the release.

Three upgrade methods compared

A major upgrade changes the internal storage format. Simply swapping packages as with minor updates is not enough. The PostgreSQL documentation describes three methods (Upgrading a PostgreSQL Cluster):

For the dump, the documentation recommends using pg_dump and pg_dumpall from the newer version. Whatever the method: a current, tested backup before the upgrade, and the "Migration" section of the release notes for every skipped version.

In-place upgrade from 14 to 18

pg_upgrade supports upgrades from version 9.2 directly to the current major version (pg_upgrade). No intermediate step via 15, 16 or 17 is required. The procedure in brief:

1. Install PostgreSQL 18 packages alongside 14, including all extensions in versions for 18.
2. Create a new cluster with initdb, using the same settings for encoding, locale and data checksums.
3. Run pg_upgrade --check. The check also works while the old server is still running.
4. Stop the old server and run pg_upgrade with the chosen transfer mode.
5. Transfer and review the configuration (postgresql.conf, pg_hba.conf), start the new server.
6. Generate missing statistics: vacuumdb --all --analyze-in-stages --missing-stats-only, then vacuumdb --all --analyze-only.

Transfer modes. The default --copy copies all data files. --clone and --copy-file-range use more efficient file system copy mechanisms. --link uses hard links and is much faster, but the old cluster can no longer be used once the new one has been started. The --swap mode, new in 18, moves the data directories; once the file transfer begins, the old cluster is modified and must not be started again. With link and swap, the only way back is a backup.

Data checksums. From PostgreSQL 18, initdb enables data page checksums by default. pg_upgrade requires the old and new cluster to have the same setting (Release Notes 18, Migration). Many PostgreSQL 14 clusters run without checksums. Two solutions: create the new cluster with initdb --no-data-checksums, or first enable checksums in the stopped old cluster with pg_checksums. pg_checksums requires a cleanly shut down server and rewrites the affected blocks; according to the documentation this can take a long time on large databases.

Streaming replication. Physical standbys cannot run across major versions. After the primary has been upgraded, standbys are either rebuilt or, if pg_upgrade ran in link mode, updated using the rsync procedure described in the pg_upgrade documentation. High-availability setups with Patroni or repmgr need their own procedure, tested in advance.

Statistics. pg_upgrade in version 18 transfers most planner statistics. Extended statistics created with CREATE STATISTICS, statistics added by extensions and the cumulative statistics (pg_stat_*) are not transferred. Without the follow-up vacuumdb runs, individual queries may get worse plans after the upgrade.

Upgrading via logical replication

Logical replication works between different major versions. This makes it possible to set up a new server running PostgreSQL 18 as a subscriber of a PostgreSQL 14 server, synchronise it while the system is running and switch over at a defined point in time. According to the documentation, the interruption is limited to a few seconds (Upgrading via Replication).

The restrictions of logical replication also apply to this method (Restrictions):

The sequence replication in PostgreSQL 19 does not help with an upgrade from 14, because the source does not support it. The switchover itself consists of: stop writes on the source, wait for the replication lag to clear, set sequences, point the application to the new server. A way back remains possible as long as no data is lost on the old server; a way back after writes on the new server requires replication in the opposite direction.

This method also fits when the upgrade coincides with a change of server or location, for example moving from a hyperscaler's managed database service to your own infrastructure. How that works with dump and restore is shown in the guides on migrating from AWS RDS and Azure Database for PostgreSQL.

Incompatibilities between version 14 and 18

When moving from 14 to 18, the migration notes of versions 15, 16, 17 and 18 all apply. A selection of the items that frequently come up in practice:

Sources: migration sections of the Release Notes 15 and Release Notes 18. The table does not replace reading the release notes for 16 and 17, which contain further changes to functions, system catalogs and configuration parameters.

The MD5 deprecation deserves particular attention. PostgreSQL 19 already issues a warning after a successful MD5 login, and removal is announced for a future version. If you are upgrading anyway, converting passwords to SCRAM-SHA-256 in the same step is the sensible approach.

Pre-upgrade checklist

A test run on a copy is the most important item. It shows the actual runtime, missing extension packages and errors from pg_upgrade --check before the production maintenance window starts.

Our approach at WZ-IT

1. Assessment. All PostgreSQL instances with version, extensions, replication, backup method and dependent applications.
2. Target version and method. Choice of target version (usually 18, or 17 where certification is missing) and upgrade method based on data volume, permitted downtime and infrastructure.
3. Test run. Upgrade on a copy of production data, runtime measurement, tests agreed with the application owners.
4. Execution. Upgrade in the agreed maintenance window with a documented fallback plan, followed by statistics, application checks and monitoring.
5. Operations. On request, WZ-IT takes over ongoing operation of PostgreSQL with monitoring, backups, restore tests and regular minor updates, as part of Managed Operations and CVE monitoring.

We carry out upgrades on your own infrastructure, on-premise or on servers in German data centres. If the upgrade coincides with a move away from a hyperscaler, we combine both with an approach from our migration services.

Further guides

• Migrating AWS RDS and Aurora PostgreSQL to Hetzner, step-by-step migration with pg_dump and pg_restore.
• Migrating Azure Database for PostgreSQL to Hetzner, procedure and pitfalls when leaving Azure.
• MySQL, MariaDB and Percona compared, the MySQL family and how it differs from PostgreSQL.
• CVE monitoring for self-hosted software, tracking vulnerabilities and versions systematically.
• PostgreSQL at WZ-IT, installation, operations, replication and backups.

Replace PostgreSQL 14 before 12 November We review your instances, test the upgrade on a copy and carry out the switch to PostgreSQL 18 in an agreed maintenance window. Book a meeting

Sources

• PostgreSQL, Versioning Policy
• PostgreSQL, release schedule (roadmap)
• PostgreSQL 18.6, 17.11, 16.15, 15.19, 14.24 and 19 Beta 3, release announcement of 13 Aug 2026
• PostgreSQL, CVE-2026-16239
• PostgreSQL 19 Beta 4, announcement of 24 Sep 2026
• PostgreSQL 19, release notes
• PostgreSQL 18, release announcement
• PostgreSQL 18, release notes
• PostgreSQL 15, release notes
• PostgreSQL 18, Upgrading a PostgreSQL Cluster
• PostgreSQL 18, pg_upgrade
• PostgreSQL 18, pg_checksums
• PostgreSQL 18, Logical Replication Restrictions
• PostgreSQL Wiki, Apt repository
• Ubuntu Packages, postgresql in Jammy (22.04)