PostgreSQL 14 extended support
PostgreSQL 14 extended support:
keep 14 patched after 12 November 2026
PostgreSQL 14 end of life is 12 November 2026, and after that date the community publishes no more security or data-corruption fixes for it. OSSeva provides PostgreSQL 14 extended support: patched, signed builds, 24/7 support and audit evidence for 14 on your own servers. Send your work email and an engineer replies within 1 business day.
| Who it is for | Teams running PostgreSQL 14 on their own servers: VMs, bare metal, Kubernetes, EC2 |
|---|---|
| What you get | Backported security and data-corruption fixes, signed builds, 24/7 support, SBOM and VEX evidence |
| How it is priced | Per cluster, with no per-vCPU charge. Ask for a quote. |
| What happens next | You send your email, we confirm versions and extensions, you get a coverage plan |
Trusted globally by enterprises
PostgreSQL 14 end of life: what changes on 12 November
The PostgreSQL project supports each major version for five years and then ships one final minor release. For 14 that is 12 November 2026. From then on there are no community minor releases for 14: no security fixes, no data-corruption fixes, and no packaging updates for newer operating systems. PostgreSQL has no long-term support (LTS) release, so every major version ends the same way. Extended support is how you get fixes for a version after that date.
| Version | Community end of life | Status | OSSeva coverage |
|---|---|---|---|
| 11 | 9 Nov 2023 | End of life | Patched builds |
| 12 | 21 Nov 2024 | End of life | Patched builds |
| 13 | 13 Nov 2025 | End of life | Patched builds |
| 14 | 12 Nov 2026 | Ends in weeks | Patched builds from 12 Nov 2026 |
| 15 | 11 Nov 2027 | Supported | Covered on Assure and Operate |
| 16 | 9 Nov 2028 | Supported | Community-supported |
Dates checked 20 October 2026 against endoflife.date and the PostgreSQL versioning policy. The date-by-date detail for 14 is on the PostgreSQL 14 end of life page.
What a version misses once it stops: the 2026 numbers
The 2026 minor releases (12 February, 14 May and 13 August) fixed 44 CVEs, and PostgreSQL scored 28 of them 7.0 or higher. PostgreSQL 13, 12 and 11 received none of those fixes. PostgreSQL 14 was listed as affected by 36 of the 44, 24 of them scored 7.0 or higher, so a 14 server that had reached end of life on 1 January 2026 would have missed all of them. The project assesses supported versions only, so the count for 13 and older is not assessed, which is not the same as safe. Counts and sources are in PostgreSQL vulnerabilities by version.
Upgrade, cloud extended support, or patched builds
Most estates use more than one. Upgrade the clusters you can move, and cover the rest. If an upgrade to 17 or 18 is the better answer for a cluster, OSSeva engineers say so and can run it.
| Option | What it is | Right when | The catch |
|---|---|---|---|
| Upgrade to 17 or 18 | A planned pg_upgrade or logical-replication move, with an extension audit and a rehearsal. | Servers you can move before the date. This is the destination for every cluster in the end. | Scope depends on schema size, extension use, code volume and the downtime window you can get. |
| Cloud extended support | Amazon RDS and Aurora enrol PostgreSQL 14 automatically from 1 March 2027, billed per vCPU-hour.RDS Extended Support cost calculator → | Databases that already run on RDS or Aurora and will stay there. | Only inside that managed service, and the bill follows vCPU count and doubles in year 3. |
| Patched PostgreSQL 14 builds | OSSeva backports security and data-corruption fixes to 14 from the community date and signs every build. | Self-managed PostgreSQL on VMs, bare metal, Kubernetes or EC2 that cannot all move in time. | A subscription per cluster for as long as you stay on 14. It buys time; it does not replace the upgrade. |
Amazon RDS dates from the AWS RDS for PostgreSQL release calendar, read 20 October 2026: standard support for 14 ends 28 February 2027 and Extended Support ends 28 February 2030.
One contract across engines
PostgreSQL 14 sits on the same contract as MySQL, MongoDB, Redis, Kafka, RabbitMQ and the rest of the stack, so there is no second vendor for the databases that end next.
Priced per cluster
The model is per cluster, not per vCPU or per user. Adding cores to a busy primary does not change the support bill. Ask for a quote against your own fleet.
24/7 cover
Assure includes 24/7 reactive support: raise an issue at any hour. Operate adds proactive 24/7 monitoring and a 15-minute P1 response.
Runs on your infrastructure
Signed packages and images install like a minor release on the same data directory, under Patroni or repmgr. Your data and your servers stay yours.
What OSSeva patches and how builds are signed
Each build is the last community minor release for 14 plus backported fixes for the security and data-corruption issues fixed on the supported branches since. That covers the core server, client tools such as psql and pg_dump, libpq and the contrib modules. Releases follow the community's quarterly minor-release schedule, with out-of-cycle releases for CVSS 9.0 and higher. OSSeva targets 48 hours for Critical CVEs and 7 days for High.
- Delivered as signed DEB and RPM packages, tarballs and container images.
- Extension compatibility is validated for each release. Third-party extensions such as PostGIS, pgvector and TimescaleDB are maintained by their own communities, and OSSeva tells you which is which before you buy.
- Installs like a minor release on the same data directory, under Patroni or repmgr, so there is no dump and reload.
How to verify a package or an image is in OSSeva security. Coverage by tier is on the PostgreSQL support page, and managed PostgreSQL covers running the cluster for you.
Sample attestation pack
Auditors and customers ask the same question about an end-of-life database: what is in it, and what has been fixed. The attestation pack for a patched build answers it with three documents.
SBOM
A software bill of materials for each patched build, in CycloneDX and SPDX formats, so you can see exactly what is in the package you run.
VEX statements
Which advisories are fixed in the build and which do not apply, so a scanner finding on 14 can be answered with evidence instead of an argument.
Signed-build verification
GPG signatures on packages, Sigstore cosign signatures on container images and SHA-256 checksums, with the commands to verify them.
Who sells security patches for PostgreSQL 14 after end of life?
For PostgreSQL you run yourself, OSSeva sells patched, signed PostgreSQL 14 builds from the community end-of-life date of 12 November 2026, on the Patch, Assure and Operate tiers, priced per cluster. For databases on Amazon RDS or Aurora, AWS sells its own Extended Support from 1 March 2027, billed per vCPU-hour and only inside the managed service. Other independent providers also sell PostgreSQL support, so compare which versions, which fixes and which response terms each one commits to.
Which vendors offer extended security support for PostgreSQL 13 after it reached end of life?
PostgreSQL 13 reached community end of life on 13 November 2025. If it runs on Amazon RDS or Aurora, AWS sells Extended Support for it from 1 March 2026 to 28 February 2029. If it runs on your own servers, independent providers sell patched builds, and OSSeva is one: it ships signed builds with backported security and data-corruption fixes for 11, 12 and 13, and for 14 from 12 November 2026.
When does PostgreSQL 14 reach end of life?
12 November 2026, five years after its first release on 30 September 2021. The final 14.x minor release ships that day and the community publishes no security or data-corruption fixes for 14 after it. Dates checked against endoflife.date on 20 October 2026. Amazon RDS and Aurora keep 14 in standard support until 28 February 2027.
Is there a PostgreSQL LTS release?
No. The PostgreSQL project supports every major version for five years and then stops, so none has a longer support window. Getting fixes beyond that date means extended support from a third party for self-managed servers, or your cloud provider's own extended support for managed databases.
What does PostgreSQL 14 extended support from OSSeva include?
Signed DEB and RPM packages, tarballs and container images built from the last community 14 minor release plus backported security and data-corruption fixes, on the community's quarterly schedule with out-of-cycle releases for CVSS 9.0 and higher. OSSeva targets 48 hours for Critical CVEs and 7 days for High. Assure adds major-version migration planning, a compliance attestation package and 24/7 reactive support, and Operate adds proactive 24/7 monitoring and a 15-minute P1 response.
How is PostgreSQL 14 extended support priced?
Per cluster, across the Patch, Assure and Operate tiers. It does not follow vCPU count, so adding cores to a busy primary does not change the support bill. OSSeva does not publish prices on this page; send your work email for a quote against your own clusters.
What is in the attestation pack for a patched build?
An SBOM for the build in CycloneDX and SPDX formats, VEX statements that say which advisories are fixed or do not apply, and the signed-build verification: GPG signatures on packages, Sigstore cosign signatures on container images and SHA-256 checksums. Use the form on this page to request a sample pack.
Can OSSeva support PostgreSQL 14 on Amazon RDS or Aurora?
No. RDS and Aurora run engine builds that only AWS can change. OSSeva is for PostgreSQL you operate yourself, on VMs, bare metal, Kubernetes or EC2. For RDS and Aurora, upgrade or use AWS Extended Support, and the RDS Extended Support calculator shows what it costs.
Does OSSeva support PostgreSQL extensions like PostGIS, pgvector, or TimescaleDB?
OSSeva's PostgreSQL patches focus on the core engine, client tools, libpq and the contrib modules. Extensions like PostGIS, pgvector and TimescaleDB are maintained by their own communities. OSSeva validates extension compatibility with each patched release and tells you which extensions are covered before you buy, but does not independently patch extension code.
How long does a PostgreSQL major version upgrade take?
It depends on your estate, not on a standard number. The drivers are schema and database size, the extensions in use, how much application code and how many stored procedures need regression testing, and the downtime window you can get for pg_upgrade or logical replication. Extended support keeps the clusters you cannot move in time patched while the upgrade is planned and run at a safe pace rather than under audit pressure.
Get a quote
Keep PostgreSQL 14 patched.
Plan the upgrade on your schedule.
Send your work email. We confirm your versions and extensions and reply with a coverage plan.
Prefer to talk or read more first?