PostgreSQL 14 reaches end of life on November 12, 2026, ending all security fixes

PostgreSQL 14 receives its final minor release on November 12, 2026. From that date the community stops shipping fixes for the version, security patches included, and any installation still running it must upgrade, with PostgreSQL 18 as the recommended destination. That is the core warning of a detailed upgrade guide published on dev.to.

A five-year support window closes

The PostgreSQL project supports each major version for five years after its first release, then ships one final minor release and stops. Version 14 arrived on September 30, 2021, so its final release lands on November 12, 2026, alongside the project's next scheduled round of minor releases. Minor releases are the channel for bug fixes, security fixes and data-corruption fixes; once they stop, anything found later in version 14 stays unfixed even though existing databases keep running.

According to the versioning schedule quoted by dev.to, the remaining supported majors end as follows: PostgreSQL 15 on November 11, 2027; 16 on November 9, 2028; 17 on November 8, 2029; and 18 on November 14, 2030. PostgreSQL 19 reached its first release candidate on October 15, 2026 but is not on the supported list yet, and the guide advises against waiting for it — version 18 is the newest supported major and has the most years of fixes left.

Version 14 hides in more places than expected

dev.to reports that roughly 72,000 public files on GitHub contain the string image: postgres:14, an approximate code-search count from November 2, 2026. The guide points to the usual hiding places: compose files and Dockerfiles pinning postgres:14, CI workflows using it as a service container, Helm values under image.tag or appVersion, and Terraform fields such as engine_version (RDS, Aurora), version (Azure) and POSTGRES_14 (Cloud SQL). An untagged image: postgres line is its own risk, since it pulls whichever major version is newest on the day the container is created.

Managed services run on their own clocks

When a cloud provider runs the database, its calendar is the one that counts. Amazon RDS for PostgreSQL keeps version 14 in standard support until February 28, 2027, then charges for Extended Support until February 28, 2030, while Google Cloud SQL, Azure and Heroku set their own dates. On managed platforms, dev.to recommends using the provider's major-version upgrade instead of the manual tooling, though the same testing steps still apply.

Three upgrade paths to version 18

A jump straight from 14 to 18 is allowed, provided the release notes for every version in between are read. The PostgreSQL upgrading documentation, as summarised by dev.to, describes three methods.

pg_upgrade fits servers you run yourself, with downtime of minutes, especially in link mode. Run the check pass first, install the version 18 build of every extension's shared library before the real run, and execute vacuumdb -a -Z afterwards, because statistics created with CREATE STATISTICS do not carry over. One wrinkle: version 18 enables data checksums by default and pg_upgrade needs both clusters to match, so a 14 cluster without checksums requires creating the new cluster with checksums off.

Dump and restore is the simplest but slowest path, best for small databases, local development and CI. Two traps stand out: an existing data volume cannot simply be pointed at postgres:18, because major versions change the data-directory format, and from version 18 the Docker image expects its volume at /var/lib/postgresql rather than /var/lib/postgresql/data.

Logical replication suits large databases that cannot go down, with switchover measured in seconds. It needs wal_level = logical on the 14 server, which requires a restart, and it has firm limits: schemas, sequences and large objects do not replicate, and tables need a replica identity for UPDATE and DELETE statements to propagate.

What to test before switching

Point CI at version 18 first, dev.to suggests, then verify extension availability, compare query plans on both versions with EXPLAIN (ANALYZE, BUFFERS) and pg_stat_statements, and update connection drivers, since version 18 deprecates MD5 passwords in favour of SCRAM. Scripts that rely on version 15 behaviour changes also need review: new databases no longer let every user create objects in the public schema, and pg_start_backup and pg_stop_backup were renamed to pg_backup_start and pg_backup_stop.

Why it matters

A version 14 database that keeps running after November 12 is not a safe one: every vulnerability found in it from that day forward will never be patched, and the GitHub file count suggests the exposure is widespread. The deadline is fixed, the direct 14-to-18 upgrade path exists, and most of the effort sits in testing extensions, drivers, permissions and query plans rather than in the migration itself.