PostgreSQL 13 end of life
PostgreSQL 13 reached end of life on 13 November 2025, five years after its release on 24 September 2020. The PostgreSQL Global Development Group supports each major version for five years and then stops: 13.23 was the final minor release. No further security or bug-fix releases will be made on the 13 line by the community.
What now
Which vendors provide PostgreSQL 13 security patches now that support has ended?
PostgreSQL 14 extended support after 12 November 2026- End of life
- 13 November 2025
- Released
- Sept 2020
- Final release
- 13.23
- Successor
- PostgreSQL 17 or 18
Date published by PostgreSQL versioning policy. We do not publish a lifecycle date we cannot source. Dates checked on endoflife.date and postgresql.org on 20 October 2026.
Last reviewed
What actually stops on 13 November 2025
- Quarterly minor releases on the 13 line. The community ships minor releases on a fixed February, May, August and November cadence; 13 is no longer in that train.
- Security fixes for server-side vulnerabilities, including any found in the planner, the wire protocol, or the authentication paths.
- Fixes for data-corrupting bugs. This is the one that matters most and that teams consistently underweight: the 13 line will not receive a corruption fix even for a confirmed, reproducible bug.
- Packaging updates from the PostgreSQL apt and yum repositories for the 13 line on newer operating systems.
What actually breaks in the upgrade
pg_upgrade is fast; the extensions are what break
A pg_upgrade from 13 to 17 with --link typically completes in minutes regardless of database size, because it relinks files rather than copying them. The failures are almost never the core upgrade. They are extensions compiled against the old server: PostGIS, pg_partman, TimescaleDB, pg_stat_statements variants and anything installed from source. Every extension has to exist, at a compatible version, for the target major before the upgrade starts.
Logical replication is the zero-downtime path, and it has sharp edges
For estates that cannot take the pg_upgrade outage, logical replication from 13 to the target gives a cutover measured in seconds. It does not replicate DDL, sequences need resetting at cutover, and tables without a primary key or replica identity will not replicate updates or deletes at all. Audit for those before you plan the window, not during it.
Managed services have their own, earlier, forced dates
RDS, Aurora, Cloud SQL and Azure Database all run their own deprecation schedules and will force a major version upgrade on their own timetable, sometimes with an automatic upgrade during a maintenance window. If the estate is managed, the provider's date usually arrives before the community one matters.
CVEs fixed since PostgreSQL 13 ended
PostgreSQL 13 ended on 13 November 2025 with 13.23, so all three 2026 minor-release sets came after it. They fixed 44 CVEs, and PostgreSQL scored 28 of them 7.0 or higher. None of those fixes has a release for 13. The project's advisories list versions 14 to 18 as affected, so 13 was not assessed. That is not a finding that it is safe.
2026 PostgreSQL security fixes and what 13 received
| Released | Fixed in supported lines | CVEs fixed | Scored 7.0 or higher | Fix for 13 |
|---|---|---|---|---|
| 12 February 2026 | 18.2 to 14.21 | 5 | 4 | No release |
| 14 May 2026 | 18.4 to 14.23 | 11 | 6 | No release |
| 13 August 2026 | 18.6 to 14.24 | 28 | 18 | No release |
Source: the CVE table on postgresql.org/support/security, counted on 20 October 2026. Scores are PostgreSQL's own as the CNA. Counts cover 2026 only; fixes published between 13 November 2025 and the end of 2025 are not included.
Your options, costed honestly
Including the ones that do not involve buying anything from us.
| Option | What it is | Effort | Cost | Our view |
|---|---|---|---|---|
| pg_upgrade to 17 or 18 | The supported path. Minutes of downtime with --link, once the extension audit is clean. | Depends on extension count, rehearsal time and downtime window | Engineering time | The right answer for most estates. The upgrade itself is rarely the hard part. |
| Logical replication cutover | Stand up the target, replicate, cut over in seconds. | Depends on the replica-identity audit and the cutover window | Engineering time plus temporary double infrastructure | Right when downtime is genuinely unaffordable. Do not choose it to avoid the extension audit; you still need one. |
| Extended support on 13 | Keep 13 and take backported security and corruption fixes from a third party. | Days to onboard | Subscription per instance or estate | Right when an application vendor has not certified a newer major, or when the audit arrives before the migration can. |
| Stay on 13 unpatched | No patches for security or data-corruption bugs. | None | Zero now | The corruption exposure, not the CVE exposure, is what should decide this. A database that can silently corrupt data is a different category of risk from an application runtime. |
What OSSeva does for PostgreSQL 13
OSSeva patches this line
OSSeva backports security and data-corruption fixes to PostgreSQL 13 and ships signed packages and container images through your repository manager. We patch the server. We do not maintain third-party extensions: if you run PostGIS or TimescaleDB on 13 we will tell you which fixes we can carry and which sit with the extension maintainer, before you sign anything.
PostgreSQL extended supportWhat your auditor will say
Requirement 6.3.3 applies to the database as a system component. An unsupported major with no patch source is a finding; a documented third-party patch stream is the usual remediation.
CC7.1 and the availability criteria both bite here, because an unpatched data-corruption bug is an availability and integrity issue as much as a security one.
The security rule's integrity controls (164.312(c)) are about protecting ePHI from improper alteration. Running a database version that will not receive corruption fixes is directly relevant to that control.
When did PostgreSQL 13 reach end of life?
13 November 2025, five years after its release on 24 September 2020. The final minor release on the line was 13.23. PostgreSQL supports each major version for five years under its published versioning policy.
Is PostgreSQL 13 still supported?
Not by the community. The PostgreSQL Global Development Group ships no further minor releases, security fixes or bug fixes on the 13 line. Third-party extended support is available.
Is it safe to keep running PostgreSQL 13?
The risk is not only security. Unsupported majors stop receiving fixes for data-corruption bugs, which for a database is the more serious exposure. For a regulated or high-integrity workload this is difficult to accept without a patch source.
What should I upgrade PostgreSQL 13 to?
17 or 18. Both are current; 17 is supported to 8 November 2029 and 18 to 14 November 2030. Skip 14 as a stepping stone: its own support window is almost over, so upgrading 13 to 14 buys almost nothing.
How long does a PostgreSQL 13 upgrade take?
pg_upgrade with --link usually completes quickly regardless of database size. The work is the extension audit and the rehearsal around it, and it grows with the number of extensions and the downtime window you can get. A logical replication cutover trades more planning for seconds of downtime.
Can I get security patches for PostgreSQL 13?
Yes, from a third-party provider. OSSeva backports security and corruption fixes to the 13 line and ships signed packages and images. The community does not.
What breaks in a PostgreSQL major version upgrade?
Rarely the core server. It is almost always extensions compiled against the old major — PostGIS, pg_partman, TimescaleDB — or application code relying on behaviour that changed, most often in the query planner or in default collation handling.
How many security fixes has PostgreSQL 13 missed since it ended?
The three 2026 minor-release sets, on 12 February, 14 May and 13 August, fixed 44 CVEs, and PostgreSQL scored 28 of them 7.0 or higher. None has a release for 13. The count comes from the CVE table on postgresql.org/support/security, counted on 20 October 2026.
Which PostgreSQL versions are still supported, and when does each end?
14 ends on 12 November 2026, 15 on 11 November 2027, 16 on 9 November 2028, 17 on 8 November 2029 and 18 on 14 November 2030, per the PostgreSQL versioning policy, checked 22 October 2026. 13 has already ended.
Does an unsupported PostgreSQL version fail an audit?
It is a finding under PCI DSS 4.0 requirement 6.3.3 and SOC 2 CC7.1 unless you can show a remediation path. A named third-party patch source with a published cadence is the evidence assessors accept most readily.
Get a quote
Still running PostgreSQL 13?
Tell us the versions and the estate size. We will tell you honestly whether to upgrade or to buy cover — and we say 'upgrade' more often than you would expect.
Prefer to talk or read more first?