PostgreSQL 14 reached the end of its upstream support period on 12 November 2026. Its final release, 14.25, arrived alongside PostgreSQL 18.7, 17.12, 16.16 and 15.20 in a large security update. The PostgreSQL Global Development Group announcement reports 52 security vulnerabilities and more than 140 bug fixes across the release.

For anyone running PostgreSQL 14, there are now two separate decisions. The first is whether the existing database has received the final fixes. The second is how it will move to a supported major version. Installing 14.25 addresses the first decision; it does not restart the support clock.

The timing also matters for managed database customers. A cloud provider may continue offering a version after the community's end-of-life date under its own support arrangement. The existence of a database instance in a provider's console does not establish that it still receives upstream security maintenance.

Which PostgreSQL versions received the November update?

The stable releases announced on 12 November are:

  • PostgreSQL 18.7
  • PostgreSQL 17.12
  • PostgreSQL 16.16
  • PostgreSQL 15.20
  • PostgreSQL 14.25, the final release of the 14 series

The project also released PostgreSQL 19 RC 2. That is a release candidate, not the production general-availability release. The announcement gives 19 November as the planned date for PostgreSQL 19's general availability.

The PostgreSQL versioning policy gives a major version five years of community support. Minor releases deliver accumulated corrections during that period. In the current numbering scheme, 14.24 to 14.25 is a minor update, while 14 to 18 is a major upgrade.

A minor update ordinarily replaces server software without exporting and reloading the database. A major upgrade must address changes in internal database structures. They are different maintenance events even if a provider exposes both through the same management interface.

Why the security fixes matter on private database networks

A database does not need to accept connections from the public internet for its privilege boundaries to matter. Application accounts, reporting users, extensions and replication processes may already have access to SQL. Many systems depend on restricting what these identities can do after authentication.

Three examples from the November release illustrate the problem:

  • CVE-2026-6460, scored 8.8, involves type confusion. An object creator can potentially execute code with the permissions of the operating system account running PostgreSQL.
  • CVE-2026-6467, scored 7.2, involves trusted extension scripts resolving the wrong schema object. An attacker with database-level CREATE privileges can potentially execute SQL with elevated privileges.
  • CVE-2026-120154, scored 4.3, allows an attacker with INSERT, UPDATE and applicable SELECT privileges to read rows despite row-level security policies. This particular flaw does not enable improper writes.

These are not 52 interchangeable remote takeover bugs. The prerequisites, affected versions and consequences differ. The last example is particularly relevant to applications using row-level security to separate customers' records. An authorization weakness may matter greatly in that environment even when its numerical severity is lower than a memory-safety vulnerability.

A database shared by several tenants presents a different risk from one accessible only to a narrowly privileged application account. Neither arrangement is a reason to disregard the update.

Some corrections require more than replacing the server binaries

The November announcement devotes a separate section to post-update work. It identifies issues with indexes, partition constraints, backups and snapshots taken on standbys. Existing data structures may need attention even after the defect that caused the problem has been fixed.

The project recommends rebuilding GIN indexes where corruption is suspected. It calls for reindexing GiST indexes that use the pg_trgm extension's gist_trgm_ops operator class. B-tree indexes on columns declared as bpchar without a length also need reindexing; this is not the same as an ordinary fixed-length char(n) declaration.

The release notice advises users of incremental backups to establish a fresh full backup after updating. It also describes checks for certain constraints on partitioned tables and for tables producing missing-chunk errors in their TOAST storage. The relevant release notes explain which issues apply to each major version and database configuration.

A database may restart quickly after a software update, yet rebuilding a large index can consume considerable storage bandwidth and take much longer. A fresh backup also requires time and storage capacity. Availability during this work depends on the maintenance method and database topology.

For a fleet, a report showing that every server has the new binaries is useful but incomplete. The applicable release-specific follow-up work must also be assessed. In particular, a backup taken before an integrity issue was noticed should not be assumed to be an error-free recovery copy simply because the backup job reported success.

PostgreSQL 14 to 18 is a separate migration project

The pg_upgrade documentation for PostgreSQL 18 explains how the utility can move data to a newer major version without the full export and import otherwise needed for a logical dump and restore. It relies on compatible data files and creates new system tables. External modules and extensions still have to be compatible with the target installation.

A logical dump and restore reconstructs database objects and data on the new version, which can be useful when the target environment needs to change substantially. For a large database, transferring and rebuilding data can take considerable time. Logical replication may also form part of a migration design, but it requires careful treatment of schema changes, sequences and cutover consistency.

A small internal database might tolerate a planned interruption. A busy multi-tenant database with extensive extensions, a large write volume or a strict recovery objective may need a staged migration and a tested rollback arrangement. There is little value in extending the database's support period if an essential application or extension becomes unsupported in the process.

What end of life means for managed PostgreSQL

Community end of life means the PostgreSQL project will no longer issue security and bug-fix releases for that major version. It does not mean the database immediately stops accepting queries.

Some managed providers offer extended support or have separate migration deadlines, sometimes with additional charges. Those commitments are provider-specific and need to be evaluated against the actual service plan. An extended-support arrangement can give a business more migration time, but it is not automatically equivalent to the community's normal release cadence.

The final 14.25 update closes the vulnerabilities covered by that release. It does not provide a future 14.26 community security release. A move away from PostgreSQL 14 is therefore a compatibility and reliability change as well as a security decision. A supported version, maintained database structures and a tested recovery copy are three separate parts of keeping the service reliable.