Postgres 13 end of life was November 13, 2025, when the community shipped the final release, 13.23. Nothing has been patched since. On AWS RDS and Aurora, standard support for 13 ended on February 28, 2026, so since March 1 every PG13 instance there has been billing for RDS Extended Support.
The upgrade target is PostgreSQL 17 or 18. Do not stop at 14. It reaches end of life on November 12, 2026, about six weeks from now.
Key Takeaways
- PostgreSQL 13 reached end of life on November 13, 2025, per the official PostgreSQL versioning policy.
- Upgrade to 17 (supported to November 2029) or 18 (to November 2030). Version 14 ends November 12, 2026.
- RDS and Aurora PG13 have been on paid Extended Support since March 1, 2026, and the rate doubles from March 2028.
- For most startup databases the work is one to two engineer-weeks; the risky parts are extensions and query plans, not data.
Postgres 13 End of Life and Which Version to Pick
PostgreSQL supports each major version for five years, then ships one final minor release. The table:
| Version | Community end of life | RDS end of standard support |
|---|---|---|
| 13 | Nov 13, 2025 | Feb 28, 2026 (Extended Support to Feb 28, 2029) |
| 14 | Nov 12, 2026 | Feb 28, 2027 |
| 15 | Nov 11, 2027 | Feb 29, 2028 |
| 16 | Nov 9, 2028 | Feb 28, 2029 |
| 17 | Nov 8, 2029 | Feb 28, 2030 |
| 18 | Nov 14, 2030 | Feb 28, 2031 |
RDS dates come from the RDS for PostgreSQL release calendar. Aurora PostgreSQL 13 follows the same dates.
My pick for most teams is 17. It has two years of production mileage, extension support is broad, and it gives you three years before you think about this again. Choose 18 if you want the longest runway and your extensions already support it.
How to Upgrade: pg_upgrade, Blue/Green, or Logical Replication
There are three practical paths:
- pg_upgrade (self-hosted or what RDS runs under the hood for in-place upgrades). The official pg_upgrade docs note it supports upgrades from 9.2 onward. `--link` mode is fastest, but "you will not be able to access your old cluster once you start the new cluster", so take a snapshot first. `--clone` leaves the old cluster untouched if your storage supports it.
- RDS Blue/Green deployment. A staging copy on the new version, kept in sync, then a switchover. Downtime is typically the switchover itself.
- Logical replication to a new cluster. Most control, most work. Worth it for large databases or when you are also changing instance class or region.
What Actually Goes Wrong
The data almost always comes across fine. These are the things that cause late nights:
1. Extensions. The new cluster needs the extension binaries installed first. The pg_upgrade docs are blunt: "Do not load the schema definitions, e.g., CREATE EXTENSION pgcrypto." PostGIS and anything less common needs a version check against the target.
2. Statistics. Going to 18, pg_upgrade transfers most optimizer statistics, but not `CREATE STATISTICS` objects; run `vacuumdb --all --analyze-in-stages --missing-stats-only` afterwards. Going to 17, plan on no statistics at all and run `vacuumdb --all --analyze-in-stages` before taking traffic. Skip this and your first hour runs on bad plans.
3. Query plans. New planner, same queries, sometimes different plans. Replay your slowest 50 queries against the new version before switching.
4. reg\* types. pg_upgrade fails on columns using types like `regproc` or `regoper`. `regclass`, `regrole` and `regtype` are fine.
5. Driver and ORM versions. Old drivers usually work, but check before, not during.
A Concrete Version
A health-tech startup runs RDS PostgreSQL 13: a primary with 8 vCPU and a Multi-AZ standby with 8 vCPU. That is 16 vCPU billed for Extended Support.
AWS's RDS for PostgreSQL pricing page uses a US East (Ohio) example: $0.100 per vCPU-hour in years one and two, $0.200 from year three, with no Reserved Instance discounts. Your region may differ. Using that example:
- 16 vCPU x $0.100 x 730 hours = $1,168 per month, about $14,000 a year.
- From March 2028: 16 x $0.200 x 730 = $2,336 per month.
The upgrade to 17, for a 200 GB database with PostGIS and pgcrypto:
- Extension compatibility check, test restore of a snapshot on 17: 2 days.
- Replay of slow-query log and plan comparison, two index fixes: 3 days.
- Blue/Green setup, ANALYZE run, rehearsal of switchover and rollback: 2 days.
- Production switchover in a low-traffic window, post-checks: 1 day.
8 engineer-days. Compared with $14,000 a year in Extended Support for one cluster, this one is not close.
The Honest Counterpoint
Extended Support exists for good reasons, and paying it can be rational. If the database is scheduled to be decommissioned in a few months, or a platform migration is already underway, a short stretch of support fees beats an upgrade you will throw away. And a tiny 2 vCPU instance costs about $146 a month under the Ohio example; that is cheap insurance while you plan.
The trap is drift. AWS keeps billing until February 28, 2029, and the rate doubles in 2028. Teams that "decide later" usually end up paying for two years without deciding anything. That is the same pattern behind most technical debt. If your database work is part of a bigger cleanup, start with how to hire developers to modernize a legacy app. If you also run MySQL, see the MySQL 8.0 end of life post. And if your app servers are still on Node 20, bundle that upgrade into the same quarter.
Frequently Asked Questions
When was Postgres 13 end of life?
November 13, 2025. The final release was 13.23. On RDS and Aurora, standard support ended February 28, 2026.
Should I upgrade Postgres 13 to 14, 16 or 17?
17 or 18. Version 14 reaches end of life on November 12, 2026 and 16 on November 9, 2028. Version 17 is supported until November 2029.
How much does RDS Extended Support for Postgres 13 cost?
It is charged per vCPU-hour on primaries, standbys and read replicas. AWS's US East (Ohio) example is $0.100 per vCPU-hour for years one and two, then $0.200 from March 1, 2028. Rates vary by region.
The Bottom Line
Postgres 13 is past end of life and, on AWS, already costing you money every month. The upgrade is usually one to two engineer-weeks, and the hard parts are extensions and plans, not data. If your team cannot fit it in, a senior backend or DevOps engineer can run it start to finish. Request a shortlist.
Roberto Espinoza is CEO of Ruzora, which helps US startups hire pre-vetted senior LATAM engineers, with a vetted shortlist in 72 hours. See available engineers.
