If you’re running PostgreSQL in production, understanding the database’s end-of-life (EOL) policy isn’t just about staying current – it’s about maintaining the security, performance, and reliability of your data infrastructure. With PostgreSQL 13 having reached EOL on November 13, 2025, and other PostgreSQL versions approaching their support deadlines, now is the time to assess your upgrade strategy.
Understanding PostgreSQL’s End of Life Policy
The PostgreSQL Global Development Group follows a predictable and transparent support policy: each major version of PostgreSQL receives five years of support from its initial release date. During this period, the community releases regular updates containing bug fixes, security patches, and performance improvements.
When a major version reaches its five-year anniversary, the development team releases one final minor version containing critical fixes before officially ending support. After EOL, no further security patches or bug fixes are provided, leaving databases vulnerable to newly discovered security issues and unpatched bugs.
Currently Supported PostgreSQL Versions
As of December 2025, the following major versions remain under active support:
- PostgreSQL 18 (Released September 2025) – Latest version with advanced I/O subsystem improvements
- PostgreSQL 17 (EOL: November 2030)
- PostgreSQL 16 (EOL: November 2029)
- PostgreSQL 15 (EOL: November 2028)
- PostgreSQL 14 (EOL: November 2026)
PostgreSQL 13 reached end of life on November 13, 2025, and is no longer receiving updates. PostgreSQL 12 reached EOL in November 2024.
Why Upgrading Matters When Dealing PostgreSQL End of Life
Operating an unsupported PostgreSQL version exposes your organization to significant risks:
- Security Vulnerabilities: Without security patches, your database becomes increasingly vulnerable to exploits. The recent November 2025 release addressed critical issues including authorization flaws and integer wraparound vulnerabilities—fixes that won’t be available for EOL versions.
- Compliance Issues: Many regulatory frameworks require organizations to run supported software versions. Operating EOL databases can result in compliance violations in industries like healthcare (HIPAA), finance (PCI-DSS), and others.
- Performance Degradation: Newer versions include query planner improvements, index optimizations, and hardware acceleration support that can significantly improve performance.
- Missing Features: Each new major version introduces valuable capabilities. PostgreSQL 18, for example, includes asynchronous I/O support demonstrating up to 3× performance improvements in certain workloads.
PostgreSQL Upgrade Methods: Choosing Your Path
PostgreSQL offers three primary upgrade approaches, each with distinct advantages and trade-offs.
Method 1: pg_upgrade (Recommended for Most Use Cases)
The pg_upgrade utility performs in-place upgrades by creating new system tables while reusing existing data files. This approach is significantly faster than dump/restore, especially for large databases.
Advantages:
- Fast upgrade times (minutes instead of hours)
- Minimal disk space requirements with link mode
- Preserves database configuration and settings
Considerations:
- Requires both old and new PostgreSQL binaries
- Brief downtime required during upgrade
- Same server architecture recommended
Step-by-Step: Upgrading with pg_upgrade
Step 1: Pre-Upgrade Preparation
# Check current version
psql -c “SELECT version();”
# Review installed extensions
psql -c “SELECT * FROM pg_extension;”
# Verify extension compatibility with target version
# Check release notes for any breaking changes
Step 2: Install New PostgreSQL Version
# Example for RHEL/CentOS systems
sudo yum install postgresql16-server postgresql16-contrib
# Initialize new cluster
sudo /usr/pgsql-16/bin/postgresql-16-setup initdb
Step 3: Stop Old PostgreSQL Server
sudo systemctl stop postgresql-13
Step 4: Run pg_upgrade with Compatibility Check
# Perform compatibility check (doesn’t modify data)
sudo -u postgres /usr/pgsql-16/bin/pg_upgrade \
–old-bindir /usr/pgsql-13/bin \
–new-bindir /usr/pgsql-16/bin \
–old-datadir /var/lib/pgsql/13/data \
–new-datadir /var/lib/pgsql/16/data \
–check
Step 5: Execute Upgrade
# Run actual upgrade (add –link for faster completion)
sudo -u postgres /usr/pgsql-16/bin/pg_upgrade \
–old-bindir /usr/pgsql-13/bin \
–new-bindir /usr/pgsql-16/bin \
–old-datadir /var/lib/pgsql/13/data \
–new-datadir /var/lib/pgsql/16/data \
–link
Step 6: Post-Upgrade Tasks
# Start new PostgreSQL server
sudo systemctl start postgresql-16
# Update optimizer statistics
./analyze_new_cluster.sh
# After verification, clean up old cluster
./delete_old_cluster.sh
Method 2: pg_dump and pg_restore (Maximum Flexibility)
Logical backup and restore provides complete control over the upgrade process and works across any major version gap.
Advantages:
- Works for any version upgrade path
- Opportunity to reorganize database structure
- Can upgrade between different architectures
- Removes database bloat
Considerations:
- Longer downtime for large databases
- Requires sufficient disk space for dump files
- More labor-intensive process
Step-by-Step: Upgrading with pg_dump/pg_restore
Step 1: Backup Global Objects
# Dump roles, tablespaces, and other global objects
pg_dumpall –globals-only > globals.sql
Step 2: Create Database Dumps
# Dump individual databases
pg_dump -Fc -v -d production_db > production_db.dump
# Or dump all databases at once
pg_dumpall > complete_backup.sql
Step 3: Install and Initialize New Version
# Install new PostgreSQL version
sudo yum install postgresql16-server
# Initialize new cluster
sudo /usr/pgsql-16/bin/postgresql-16-setup initdb
# Start new server
sudo systemctl start postgresql-16
Step 4: Restore Global Objects
psql -f globals.sql
Step 5: Restore Database
# Create database
psql -c “CREATE DATABASE production_db;”
# Restore from custom format dump
pg_restore -d production_db -v production_db.dump
# Or restore from SQL dump
psql production_db < production_db.sql
Step 6: Verify and Analyze
# Run ANALYZE to update statistics
psql -d production_db -c “ANALYZE;”
# Verify data integrity
psql -d production_db -c “SELECT schemaname, tablename FROM pg_tables WHERE schemaname = ‘public’;”
Method 3: Logical Replication (Zero-Downtime Upgrades)
For mission-critical systems requiring minimal downtime, logical replication enables live migration to a new PostgreSQL version.
Advantages:
- Near-zero downtime
- Ability to test new version before cutover
- Can replicate between different major versions
Considerations:
- Requires PostgreSQL 10 or newer as source
- More complex setup process
- Network bandwidth requirements
Implementing Logical Replication Upgrade
Step 1: Configure Publisher (Old Version)
— Enable logical replication
ALTER SYSTEM SET wal_level = ‘logical’;
— Restart required
— Create publication for all tables
CREATE PUBLICATION upgrade_pub FOR ALL TABLES;
Step 2: Prepare Subscriber (New Version)
— Create matching schema structure
— Then create subscription
CREATE SUBSCRIPTION upgrade_sub
CONNECTION ‘host=old-server dbname=production_db user=replication_user password=secure_password’
PUBLICATION upgrade_pub;
Step 3: Monitor Synchronization
— Check replication status
SELECT * FROM pg_stat_subscription;
— Verify lag
SELECT pg_current_wal_lsn(), received_lsn, latest_end_lsn
FROM pg_stat_subscription;
Step 4: Cutover Process
— On old server: Stop writes
— Wait for replication to catch up
— On new server: Disable subscription
ALTER SUBSCRIPTION upgrade_sub DISABLE;
— Update application connection strings
— Enable writes on new server
Pre-Upgrade Checklist: Don’t Skip These Steps
Before beginning any upgrade, ensure you’ve completed these essential preparations:
1. Create Comprehensive Backups
Always maintain a complete, tested backup before starting an upgrade. Verify you can successfully restore from your backups.
# Full cluster backup
pg_basebackup -D /backup/postgres_backup -F tar -z -P
2. Review Release Notes
Read the release notes for your target version and all intermediate versions. Pay special attention to:
- Deprecated features
- Changed behaviors
- Removed functionality
- Extension compatibility
3. Test in Staging Environment
Never upgrade production first. Create a staging environment that mirrors production and:
- Perform the complete upgrade process
- Run application test suites
- Execute performance benchmarks
- Validate query plans
- Test backup and restore procedures
4. Document Your Configuration
Record current settings that may need reconfiguration:
# Export current configuration
pg_dumpall –globals-only > pre_upgrade_globals.sql
# Document postgresql.conf settings
cat $PGDATA/postgresql.conf > pre_upgrade_config.txt
5. Check Extension Compatibility
— List installed extensions and versions
SELECT extname, extversion FROM pg_available_extensions
WHERE installed_version IS NOT NULL;
Verify all extensions support your target PostgreSQL version. Popular extensions like PostGIS, TimescaleDB, and pg_cron may require specific versions.
6. Schedule Maintenance Window
Plan your upgrade during off-peak hours with appropriate stakeholder communication. Include buffer time for unexpected issues.
Post-Upgrade Best Practices
After completing your upgrade, these steps ensure optimal performance and stability:
1. Update Optimizer Statistics
PostgreSQL’s query planner relies on statistics that don’t transfer during upgrades:
vacuumdb –all –analyze-in-stages
2. Reindex When Necessary
Some upgrades may require reindexing, particularly for specific data types:
— Reindex specific tables if needed
REINDEX TABLE table_name;
— Or reindex entire database
REINDEX DATABASE database_name;
3. Monitor Performance
Watch for query plan changes or performance regressions:
— Enable query logging temporarily
ALTER SYSTEM SET log_min_duration_statement = 1000; — Log queries over 1 second
SELECT pg_reload_conf();
— Monitor slow queries
SELECT query, mean_exec_time, calls
FROM pg_stat_statements
ORDER BY mean_exec_time DESC
LIMIT 20;
4. Update Connection Strings
Ensure all applications, monitoring tools, and backup systems point to the new PostgreSQL version.
5. Verify Replication
If you use streaming replication, ensure standby servers are properly upgraded and synchronized.
Managing Cloud PostgreSQL End of Life
AWS RDS for PostgreSQL
AWS offers Extended Support for EOL versions beyond community support dates, though this comes with additional costs. PostgreSQL 12 on RDS reached end of standard support on February 28, 2025.
Key dates:
- Extended Support available for up to 3 years past community EOL
- Additional charges apply during Extended Support period
- Major version upgrades can be automated or manual
Google Cloud SQL for PostgreSQL
Google Cloud SQL provides extended support for EOL versions with a grace period. Starting May 1, 2025, instances running EOL major versions incur extended support charges.
Upgrade options:
- In-place major version upgrade
- Database Migration Service (DMS)
- Export and import to new instance
Azure Database for PostgreSQL
Azure follows similar patterns with extended support offerings for customers requiring additional time to upgrade.
Common Upgrade Challenges and Solutions
Challenge 1: Extension Incompatibility
Solution: Check extension compatibility before upgrading. Install updated extension versions in the new cluster before restoring data.
Challenge 2: Large Database Size
Solution: For databases over 1TB, consider:
- Using pg_upgrade with –link mode
- Implementing logical replication for zero-downtime migration
- Parallelizing pg_dump with custom format and pg_restore –jobs option
Challenge 3: Custom Data Types
Solution: Review custom types for compatibility. Some may need recreation or modification in the new version.
Challenge 4: Application Code Dependencies
Solution: Audit application code for deprecated features. Common issues include:
- Removed configuration parameters
- Changed default behaviors
- Altered function signatures
Database Management Beyond Upgrades
Effective PostgreSQL management extends beyond version upgrades:
Regular Maintenance
- Vacuum: Prevent transaction ID wraparound and reclaim space
- Analyze: Keep statistics current for optimal query planning
- Reindex: Rebuild bloated indexes periodically
— Automated maintenance with pg_cron
CREATE EXTENSION pg_cron;
— Schedule weekly/daily vacuum if autovacuum process is not enough
SELECT cron.schedule(‘weekly-vacuum’, ‘0 2 * * 0’, ‘VACUUM ANALYZE’);
Monitoring Essentials
Implement comprehensive monitoring for:
- Connection counts and pool saturation
- Query performance and slow queries
- Replication lag
- Disk space utilization
- Cache hit ratios
Backup Strategy
Maintain multiple backup types:
- Continuous archiving with point-in-time recovery (PITR)
- Regular pg_dump for logical backups
- Filesystem snapshots for quick recovery
- Testing restore procedures quarterly
Security Hardening
- Keep authentication methods current
- Implement SSL/TLS for connections
- Regular security patch application
- Role-based access control (RBAC)
- Audit logging for sensitive operations
Planning Your PostgreSQL Upgrade Strategy
With PostgreSQL 13 now at end of life and other versions approaching their support deadlines, organizations should adopt a proactive upgrade strategy:
Immediate Action Required:
- PostgreSQL 13 users must upgrade immediately
- PostgreSQL 14 users should plan upgrades (EOL November 2026)
Recommended Approach:
- Inventory all PostgreSQL instances and their versions
- Prioritize critical production databases
- Create detailed upgrade timelines
- Allocate resources for testing and validation
- Establish regular upgrade cycles (every 2-3 years)
Target Versions:
- For new deployments: PostgreSQL 18 (latest features and performance)
- For critical stability: PostgreSQL 16 or 17 (mature with extended support runway)
- Avoid: PostgreSQL 14 or earlier (approaching or past EOL)
Get Expert PostgreSQL Support from Fortified Data
Navigating PostgreSQL upgrades and managing complex database environments requires expertise and experience. Whether you’re facing an urgent EOL deadline, planning a major migration, or optimizing your database infrastructure, Fortified Data’s team of certified PostgreSQL experts can help.
Our PostgreSQL Services Include:
- End-of-Life Upgrade Planning & Execution – We design and implement upgrade strategies tailored to your business requirements, minimizing downtime and risk
- Zero-Downtime Migrations – Using logical replication and proven methodologies, we can migrate your databases with minimal disruption
- Performance Optimization – Our experts analyze query performance, optimize configurations, and implement best practices for maximum efficiency
- 24/7 Database Management – Comprehensive managed services including monitoring, maintenance, backup management, and emergency support
- Cloud Database Consulting – Expert guidance for AWS RDS, Google Cloud SQL, and Azure Database for PostgreSQL environments
- Database Security & Compliance – Hardening, audit implementation, and compliance support for HIPAA, PCI-DSS, and other frameworks
With over 20 years of experience managing PostgreSQL across healthcare, financial services, and retail industries, Fortified Data has the expertise to ensure your database infrastructure remains secure, performant, and compliant.
Don’t wait until your PostgreSQL version reaches end of life.
