Back to all use cases
PostgreSQLCross-industry enterprise

The database version the application was written against

PostgreSQL supports each major version for five years, so one major line reaches end of life every November. Moving a production database to a new major version takes rehearsal and a change window, and estates with many clusters rarely finish before the date.

Challenge

The calendar is fixed. PostgreSQL 11 reached end of life on 9 November 2023, 12 on 21 November 2024 and 13 on 13 November 2025, and 14 follows on 12 November 2026 with its final minor release. After that date the community publishes no more security, bug or data-corruption fixes for the version, and the advisories name supported versions only. The August 2026 minor releases fixed 28 CVEs, and a server on 13, 12 or 11 gets none of them without a backport.

The upgrade tool is not the hard part. pg_upgrade can cross several major versions in one step, and logical replication can cut the switchover to seconds. The work around it is what takes time: an extension audit, query regression tests, a rehearsal of pg_upgrade or the logical replication cutover, and a change window on every cluster. Extensions are usually what break, and collation changes between versions can be silent.

Environment

PostgreSQL 11, 12, 13 or 14 carrying production data on self-managed servers, virtual machines or Kubernetes, usually under Patroni or repmgr for failover.

Extensions such as PostGIS, TimescaleDB or pgvector run on some clusters, and each cluster has its own owner and its own change calendar.

Options

Upgrade to 17 or 18 now. The right destination wherever it can be done safely: 17 is supported to November 2029 and 18 to November 2030, and pg_upgrade crosses several majors in one step, from 9.2 onwards.

Move to a managed service and use its extended support. Amazon RDS and Aurora keep standard support for 14 until 28 February 2027 and start paid Extended Support on 1 March 2027, charged per vCPU per hour for each instance, Multi-AZ standbys included. It covers instances on that service only.

Stay on the end-of-life version without patches. Free today, but every later security and data-corruption fix passes the server by.

Run patched builds on the clusters that cannot move in time, and schedule their upgrades cluster by cluster.

Approach

OSSeva Patch ships patched builds of PostgreSQL 11, 12 and 13 now, and 14 from 12 November 2026. Each build is the last community minor release plus backported fixes for the security and data-corruption issues fixed on the supported branches since, covering the server, client tools such as pg_dump and psql, libpq and the contrib modules. Builds are signed DEB and RPM packages, tarballs and container images, released quarterly in step with the community minor release schedule.

A patched build stays on the same major version, so it installs like a minor release: stop the server, replace the binaries, start it on the same data directory. Under Patroni the update rolls replicas first, then a switchover, then the former primary. OSSeva tests that your extensions still load and pass their checks against each build, and says which extension fixes it carries and which it does not before you sign.

OSSeva Assure plans each major-version migration to 17 or 18 and designs the cutover, pg_upgrade or logical replication, against the actual data volume and downtime budget, with a performance and vacuum configuration audit and a compliance attestation package. OSSeva Operate runs the fleet with 24/7 replication and failover monitoring and a 15-minute P1 incident response SLA.

What this delivers

Patched databases on the major version already in production, installed without pg_upgrade or a dump and restore, and major upgrades scheduled cluster by cluster on the business's terms. OSSeva PostgreSQL support is priced per cluster. The database support cost calculator estimates what your current arrangements cost from your own figures; book a discovery call for a quote.

Go deeper

Questions

Frequently asked questions

Book a 15-minute call

When does PostgreSQL 14 reach end of life?

12 November 2026, five years after its first release. The final 14.x minor release is scheduled for that day, and the community publishes no more fixes for 14 afterwards.

Does installing a patched PostgreSQL build need pg_upgrade?

No. A patched build stays on the same major version, so it installs like a community minor release on the same data directory. In a replicated cluster, update the replicas first, switch over, then update the former primary.

Which PostgreSQL versions does OSSeva patch?

11, 12 and 13 today, and 14 from 12 November 2026. PostgreSQL 15 is covered on Assure and Operate now, with Patch continuing fixes on 15 after 11 November 2027.

Are extensions such as PostGIS and pgvector covered?

Compatibility is covered; extension code is not. OSSeva tests that your extensions load and pass their checks against each patched build, and fixes inside a third-party extension stay with its maintainers.

Should we upgrade instead of buying extended support?

Wherever you can do it safely, yes. 17 and 18 are the sensible targets. Extended support is for the clusters that cannot move before their date.

See every EOL & CVE-patching use case

All use cases
Book a call