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.
- 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.
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.
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. | Days including the extension audit and a rehearsal | 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. | Weeks including the replica-identity audit | 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.
PostgreSQL 13: common questions
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. Note that 14 reaches end of life on 12 November 2026, so upgrading 13 to 14 now buys less than a year.
How long does a PostgreSQL 13 upgrade take?
pg_upgrade with --link usually completes in minutes regardless of database size. The work is the extension audit and the rehearsal around it, which is typically days. Logical replication cutovers take weeks to plan and seconds to execute.
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.
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.
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.