PostgreSQL 13 reached community end of life on November 13, 2025, and no longer receives community bug or security fixes.
The database does not stop at midnight. That is what makes end of life easy to postpone: the system keeps serving traffic while the risk quietly moves from supported maintenance to emergency migration.
Table of contents
- What PostgreSQL 13 end of life changes
- Separate community and provider timelines
- Choose a target based on support runway
- Rehearse the migration and rollback
- Validate before and after cutover
- How this fits the rest of the stack
- FAQ
What PostgreSQL 13 end of life changes
The PostgreSQL project supports each major version for about five years. After the final release, the community no longer publishes fixes for that branch. Existing servers can keep running, but newly discovered defects and vulnerabilities will not receive normal upstream patches.
Confirm the exact server and minor version with SELECT version() and inventory replicas, extensions, drivers, backup tools, scheduled jobs, and managed-provider settings. A version label on one dashboard is not a fleet inventory.
SELECT version();
SHOW server_version;
SELECT extname, extversion FROM pg_extension ORDER BY extname;Separate community and provider timelines
Cloud and managed-database providers can define their own standard-support, extended-support, forced-upgrade, or surcharge dates. Those dates do not change community EOL. Read the provider notice for the actual service and region, then plan against the earliest binding deadline.
Extended support can buy scheduling room, but it is not a reason to stop planning. Record its cost, limitations, and final deadline beside the engineering work required to leave version 13.
Choose a target based on support runway
Move to a currently supported major version accepted by your provider, extensions, and application drivers. A later target offers more runway but can include more behavior changes. Review every intervening release note rather than assuming the upgrade path is one giant compatibility leap.
Check extension versions, removed settings, authentication defaults, collation behavior, query plans, and client compatibility. Capture critical query latency before migration so post-upgrade validation has a baseline.
Rehearse the migration and rollback
The method may be pg_upgrade, logical replication, dump and restore, or a provider-managed workflow. The right choice follows database size, downtime tolerance, available disk, replication needs, and rollback requirements.
Restore a production-like backup into an isolated environment, run the upgrade, rebuild statistics where needed, and exercise application reads, writes, jobs, migrations, and failover. Measure how long each phase takes. A backup is not a rollback plan until someone has timed the restore.
Validate before and after cutover
Before cutover, confirm recent tested backups, replication health, connection strings, maintenance communication, owners, and stop conditions. Afterward, verify row counts or checksums where appropriate, extension state, error rates, slow queries, connection pools, jobs, and backup success.
Keep the old environment protected and available for the agreed rollback window without allowing split-brain writes. Then retire it deliberately so an unsupported forgotten replica does not remain part of the attack surface.
How this fits the rest of the stack
Use the RunxBuild hosting calculator to compare the database, application, storage, replicas, and transfer costs before the migration window commits. The RunxBuild dashboard is ready when the replacement database and service need a controlled deployment path.
Useful related references:
- PostgreSQL BETWEEN: Inclusive Range Queries, Indexes, and Date Traps
- PostgreSQL 18: How to Upgrade Without Downtime
- PostgreSQL Show Tables: \dt, pg_catalog, and information_schema
- Databases on RunxBuild
FAQ
What was the PostgreSQL 13 end-of-life date?
Community support ended on November 13, 2025, with the final PostgreSQL 13 minor release.
Will PostgreSQL 13 stop working after end of life?
No. Existing installations continue to run, but the community no longer provides normal bug and security fixes for that major version.
Is provider support the same as PostgreSQL community support?
No. Providers can offer different standard or extended timelines. Check the specific provider while recognizing that upstream community support has already ended.
Which PostgreSQL version should replace 13?
Choose a currently supported version compatible with your provider, extensions, drivers, and application, with enough support runway to justify the migration.
Should I use pg_upgrade or dump and restore?
It depends on database size, downtime, disk, extension compatibility, and rollback needs. Rehearse the chosen method on production-like data before cutover.