AWS Database Blog
Strategies for upgrading Amazon Aurora PostgreSQL and Amazon RDS for PostgreSQL from version 13
In this post, we help you plan your upgrade from PostgreSQL version 13 before standard support ends on February 28, 2026. We discuss the key benefits of upgrading, breaking changes to consider, and multiple upgrade strategies to choose from.
Standard support for Amazon Aurora PostgreSQL-Compatible Edition and Amazon Relational Database Service (Amazon RDS) for PostgreSQL version 13 ends on February 28, 2026.
These updates can introduce changes that affect your application compatibility. Upgrades need careful evaluation, but the latest releases offer better features, performance, and security. Plan and test thoroughly before upgrading to newer major versions to get the most benefits with the least disruption.
For detailed upgrade instructions, refer to the official documentation for both Amazon Aurora PostgreSQL-Compatible and Amazon RDS for PostgreSQL:
- Amazon Aurora PostgreSQL 13.x end of standard support is February 28, 2026
- Amazon RDS for PostgreSQL 13.x end of standard support is February 28, 2026
Key benefits of PostgreSQL newer versions
Upgrading to newer PostgreSQL versions can help improve your database performance and adds new capabilities. In this section, we list some of the features introduced in newer PostgreSQL versions.
Performance enhancements
Newer versions offer the following performance enhancements:
- Vacuum emergency mode (v14+) – Helps prevent fatal transaction ID wraparound by aggressively managing old row versions
- Improved I/O performance (v17) – Offers up to two times better write throughput with enhanced WAL processing
- Query optimization (v17+) – Provides better performance for IN clauses with B-tree indexes and parallel BRIN index builds
- Memory efficiency (v17) – New vacuum memory structure consumes up to 20 times less memory
Advanced monitoring and diagnostics
You can benefit from the following advanced monitoring and diagnostics features:
- pg_stat_io (v16+) – Provides detailed statistics on I/O operations
- pg_wait_events (v17+) – Supports in-database reference for wait events, removing manual documentation lookups
Logical replication improvements
Newer versions offer the following logical replication improvements:
- Failover support (v17+) – You can automatically synchronize logical replication slots from primary to standby servers
- Slot migration (v17+) – Logical replication slots can migrate through pg_upgrade, simplifying upgrades
- Parallel apply (v16+) – This feature writes data directly to the target table using multiple background worker processes
- Row filtering (v15+) – You have fine-grained control over what data is replicated
Developer experience
Newer versions offer an improved developer experience:
- JSONB subscripting (v14+) – Intuitive syntax for accessing and modifying JSONB data
- SQL/JSON JSON_TABLE (v17+) – The ability to transform JSON data into relational views
- Query pipelining (v14+) – Reduced network latency for high-latency connections
Security enhancements
You have access to the following security enhancements:
- pg_read_all_data and pg_write_all_data roles (v14+) – Streamlined read/write access control
- pg_maintain role (v17+) – Enabling users to perform database maintenance tasks
- (v15+) – Removal of PUBLIC creation permission on public schema
Amazon Aurora PostgreSQL-Compatible with Aurora Optimized Reads
For Amazon Aurora PostgreSQL-Compatible users, upgrading to v14.9+, v15.4+, v16.1+, and higher versions can offer more performance optimizations.
Aurora Optimized Reads delivers up to eight times faster query latency and up to 30% cost savings for large datasets. Aurora Optimized Reads supports two capabilities:
- Tiered cache – You can extend DB instance caching capacity by up to five times more instance memory (on Aurora I/O-Optimized clusters)
- Temporary objects – You can experience up to two times faster latency for advanced queries using local NVMe storage
PostgreSQL v13 deprecation: Catalog view changes and upgrade benefits (v14-v17)
Upgrading from PostgreSQL v13 to newer versions can introduce some changes that might affect your applications. In this section, we highlight changes related to system catalogs and configuration parameters.
Changes in system catalog views
The following table summarizes changes in PostgreSQL v17.
| Change Type | Column Name | Action | Notes |
| Removed from pg_stat_bgwriter | buffers_backend | REMOVED | – |
| Removed from pg_stat_bgwriter | buffers_backend_fsync | REMOVED | – |
| New View | pg_stat_checkpointer | CREATED | Separates checkpointer statistics from background writer |
| New View | pg_wait_events | CREATED | Wait event information |
The following table summarizes pg_stat_progress_vacuum column renames.
| Change Type | Old Name | New Name | Description |
| Renamed | max_dead_tuples | max_dead_tuple_bytes | Column renamed |
| Renamed | num_dead_tuples | dead_tuple_bytes | Column renamed |
| New column | – | indexes_total | New column added |
| New column | – | indexes_processed | New column added |
| New column | – | dead_tuple_bytes | New column added |
The following table summarizes additional catalog changes.
| View/Table | Change type | Old name | New name | Description |
| pg_database | New column | – | dathasloginevt | New column added |
| pg_database | Renamed | daticulocale | datlocale | Column renamed |
| pg_collation | Renamed | colliculocale | colllocale | Column renamed |
The following table summarizes modified system views.
| View name | New column(s) added |
| pg_replication_slots | failover; synced; invalidation_reason; inactive_since |
| pg_stat_progress_copy | tuples_skipped |
| pg_stat_subscription | worker_type |
| pg_stats | range_length_histogram; range_empty_frac; range_bounds_histogram |
| pg_subscription | subfailover |
The following table summarizes PostgreSQL v14 system catalog changes.
| View name | Change type | Column name | Notes |
| pg_stat_activity | New column | query_id | Requires compute_query_id parameter |
| pg_stat_statements | New column | toplevel | New column added |
Important parameter-related changes
The following table summarizes parameter-related changes in PostgreSQL v14.
| Change type | Parameter name | Description/Notes |
| New | compute_query_id | Controls query identifier computation |
| New | client_connection_check_interval | Sets the time interval between checks for disconnection while running queries |
| New | idle_session_timeout | Ends sessions not in a transaction that have been idle longer than the specified time |
| New | default_toast_compression | Sets the default compression method for compressible values |
| New | vacuum_failsafe_age | Age at which VACUUM should trigger failsafe to avoid a wraparound outage |
| New | huge_page_size | The size of huge page that should be requested |
| Removed | operator_precedence_warning | Completely removed |
| Removed | vacuum_cleanup_index_scale_factor | Removed (deprecated in v12) |
| Change type | Parameter name | Old value | New value | Description/Notes |
| Default Changed | password_encryption | md5 | scram-sha-256 | Password encryption default changed |
The following table summarizes parameter-related changes in PostgreSQL v15, v16, and v17.
| Version | Change type | Parameter name | Description/Notes |
| PostgreSQL 15 | Enhanced | wal_compression | Supports new algorithms: zstd, lz4 |
| PostgreSQL 15 | New | wal_decode_buffer_size | Buffer size for WAL decoding |
| PostgreSQL 16 | New | vacuum_buffer_usage_limit | Limits buffer usage during vacuum |
| PostgreSQL 16 | New | logical_replication_mode | Controls logical replication behavior |
| PostgreSQL 17 | New | sync_replication_slots | Enables synchronization of replication slots |
Upgrade strategy options
You have multiple approaches to upgrade your Amazon Aurora PostgreSQL and Amazon RDS for PostgreSQL database:
- In-place upgrade – You can perform this upgrade method using either the AWS Command Line Interface (AWS CLI) or AWS Management Console. In-place upgrades require downtime proportional to your database size. Test the exact duration by upgrading a snapshot first. This method suits workloads that can tolerate downtime and prefer simpler administration.
- Amazon RDS blue/green deployment – Amazon RDS blue/green deployments use PostgreSQL logical replication to maintain two synchronized environments. Upgrade the green (staging) environment using Amazon RDS one-click upgrade, test your application thoroughly, then switch production traffic with minimal downtime—typically under a minute. Although this method is simple to implement using the console or AWS CLI, be aware that DDL changes aren’t replicated and can break the replication process.
- Logical replication – Amazon Aurora PostgreSQL-Compatible and Amazon RDS for PostgreSQL support logical replication through pglogical. The process involves creating an initial snapshot of the publisher database, copying it to the subscriber, then continuously replicating real-time changes. This approach offers minimal downtime and continuous replication but requires complex initial setup and longer synchronization for large databases. Logical replication can’t replicate DDL, sequence, and large object operations.
- AWS Database Migration Service (AWS DMS) – AWS DMS supports Amazon Aurora PostgreSQL-Compatible and Amazon RDS for PostgreSQL as both source and target databases, with change data capture (CDC) capabilities. Although AWS DMS enables minimal-downtime upgrades and continuous replication, it doesn’t support all data types (like timestamp with time zone) and incurs additional costs during the migration period.
For detailed information about both in-place upgrades and various out-of-place upgrade options, refer to Upgrade your Amazon RDS for PostgreSQL or Amazon Aurora PostgreSQL database, Part 1: Comparing upgrade approaches. It examines the advantages and disadvantages of each approach.
Preparing to upgrade
Before upgrading, you should perform the following actions:
- Review your current database configuration
- Test the upgrade process in a staging environment
- Validate application compatibility
- Create comprehensive backup strategies
If immediate upgrade isn’t feasible, Amazon RDS Extended Support provides up to 3 years of continued security patches and bug fixes. RDS Extended Support is a paid service providing critical security and bug fixes for Amazon Aurora PostgreSQL-Compatible and Amazon RDS for PostgreSQL major versions up to 3 years beyond the standard support end date. Pricing increases based on years elapsed since standard support expiration. Use the RDS Extended Support window wisely to find the right upgrade path for your databases and applications. This can help you streamline your upgrade process for your production environment.
Conclusion
Upgrading from PostgreSQL v13 can give you significant performance improvements, better security features, and more efficient operations.
For detailed technical guidance, consult the official AWS documentation and consider engaging AWS support for complex migration scenarios. If you have AWS Enterprise Support, your Technical Account Manager (TAM) can provide expert guidance throughout your upgrade journey. TAMs can connect you with AWS specialists and provide targeted resources to support a seamless upgrade process.