On this submit, we enable you plan your improve from PostgreSQL model 13 earlier than commonplace help ends on February 28, 2026. We focus on the important thing advantages of upgrading, breaking adjustments to contemplate, and a number of improve methods to select from.
Commonplace help for Amazon Aurora PostgreSQL-Appropriate Version and Amazon Relational Database Service (Amazon RDS) for PostgreSQL model 13 ends on February 28, 2026.
These updates can introduce adjustments that have an effect on your software compatibility. Upgrades want cautious analysis, however the newest releases provide higher options, efficiency, and safety. Plan and check completely earlier than upgrading to newer main variations to get probably the most advantages with the least disruption.
For detailed improve directions, confer with the official documentation for each Amazon Aurora PostgreSQL-Appropriate and Amazon RDS for PostgreSQL:
Key advantages of PostgreSQL newer variations
Upgrading to newer PostgreSQL variations might help enhance your database efficiency and provides new capabilities. On this part, we record a few of the options launched in newer PostgreSQL variations.
Efficiency enhancements
Newer variations provide the next efficiency enhancements:
- Vacuum emergency mode (v14+) – Helps forestall deadly transaction ID wraparound by aggressively managing outdated row variations
- Improved I/O efficiency (v17) – Presents as much as two occasions higher write throughput with enhanced WAL processing
- Question optimization (v17+) – Gives higher efficiency for IN clauses with B-tree indexes and parallel BRIN index builds
- Reminiscence effectivity (v17) – New vacuum reminiscence construction consumes as much as 20 occasions much less reminiscence
Superior monitoring and diagnostics
You’ll be able to profit from the next superior monitoring and diagnostics options:
- pg_stat_io (v16+) – Gives detailed statistics on I/O operations
- pg_wait_events (v17+) – Helps in-database reference for wait occasions, eradicating handbook documentation lookups
Logical replication enhancements
Newer variations provide the next logical replication enhancements:
- Failover help (v17+) – You’ll be able to mechanically synchronize logical replication slots from major to standby servers
- Slot migration (v17+) – Logical replication slots can migrate via pg_upgrade, simplifying upgrades
- Parallel apply (v16+) – This characteristic writes information on to the goal desk utilizing a number of background employee processes
- Row filtering (v15+) – You will have fine-grained management over what information is replicated
Developer expertise
Newer variations provide an improved developer expertise:
- JSONB subscripting (v14+) – Intuitive syntax for accessing and modifying JSONB information
- SQL/JSON JSON_TABLE (v17+) – The power to rework JSON information into relational views
- Question pipelining (v14+) – Diminished community latency for high-latency connections
Safety enhancements
You will have entry to the next safety enhancements:
- pg_read_all_data and pg_write_all_data roles (v14+) – Streamlined learn/write entry management
- pg_maintain function (v17+) – Enabling customers to carry out database upkeep duties
- (v15+) – Elimination of PUBLIC creation permission on public schema
Amazon Aurora PostgreSQL-Appropriate with Aurora Optimized Reads
For Amazon Aurora PostgreSQL-Appropriate customers, upgrading to v14.9+, v15.4+, v16.1+, and better variations can provide extra efficiency optimizations.
Aurora Optimized Reads delivers as much as eight occasions sooner question latency and as much as 30% price financial savings for big datasets. Aurora Optimized Reads helps two capabilities:
- Tiered cache – You’ll be able to lengthen DB occasion caching capability by as much as 5 occasions extra occasion reminiscence (on Aurora I/O-Optimized clusters)
- Momentary objects – You’ll be able to expertise as much as two occasions sooner latency for superior queries utilizing native NVMe storage
PostgreSQL v13 deprecation: Catalog view adjustments and improve advantages (v14-v17)
Upgrading from PostgreSQL v13 to newer variations can introduce some adjustments which may have an effect on your purposes. On this part, we spotlight adjustments associated to system catalogs and configuration parameters.
Modifications in system catalog views
The next desk summarizes adjustments in PostgreSQL v17.
| Change Kind | Column Identify | Motion | Notes |
| Faraway from pg_stat_bgwriter | buffers_backend | REMOVED | – |
| Faraway from pg_stat_bgwriter | buffers_backend_fsync | REMOVED | – |
| New View | pg_stat_checkpointer | CREATED | Separates checkpointer statistics from background author |
| New View | pg_wait_events | CREATED | Wait occasion data |
The next desk summarizes pg_stat_progress_vacuum column renames.
| Change Kind | Previous Identify | New Identify | 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 next desk summarizes further catalog adjustments.
| View/Desk | Change kind | Previous title | New title | Description |
| pg_database | New column | – | dathasloginevt | New column added |
| pg_database | Renamed | daticulocale | datlocale | Column renamed |
| pg_collation | Renamed | colliculocale | colllocale | Column renamed |
The next desk summarizes modified system views.
| View title | 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 next desk summarizes PostgreSQL v14 system catalog adjustments.
| View title | Change kind | Column title | Notes |
| pg_stat_activity | New column | query_id | Requires compute_query_id parameter |
| pg_stat_statements | New column | toplevel | New column added |
Essential parameter-related adjustments
The next desk summarizes parameter-related adjustments in PostgreSQL v14.
| Change kind | Parameter title | Description/Notes |
| New | compute_query_id | Controls question identifier computation |
| New | client_connection_check_interval | Units the time interval between checks for disconnection whereas operating queries |
| New | idle_session_timeout | Ends periods not in a transaction which were idle longer than the required time |
| New | default_toast_compression | Units the default compression methodology for compressible values |
| New | vacuum_failsafe_age | Age at which VACUUM ought to set off failsafe to keep away from a wraparound outage |
| New | huge_page_size | The scale of big web page that must be requested |
| Eliminated | operator_precedence_warning | Utterly eliminated |
| Eliminated | vacuum_cleanup_index_scale_factor | Eliminated (deprecated in v12) |
| Change kind | Parameter title | Previous worth | New worth | Description/Notes |
| Default Modified | password_encryption | md5 | scram-sha-256 | Password encryption default modified |
The next desk summarizes parameter-related adjustments in PostgreSQL v15, v16, and v17.
| Model | Change kind | Parameter title | Description/Notes |
| PostgreSQL 15 | Enhanced | wal_compression | Helps new algorithms: zstd, lz4 |
| PostgreSQL 15 | New | wal_decode_buffer_size | Buffer measurement for WAL decoding |
| PostgreSQL 16 | New | vacuum_buffer_usage_limit | Limits buffer utilization throughout vacuum |
| PostgreSQL 16 | New | logical_replication_mode | Controls logical replication conduct |
| PostgreSQL 17 | New | sync_replication_slots | Allows synchronization of replication slots |
Improve technique choices
You will have a number of approaches to improve your Amazon Aurora PostgreSQL and Amazon RDS for PostgreSQL database:
- In-place improve – You’ll be able to carry out this improve methodology utilizing both the AWS Command Line Interface (AWS CLI) or AWS Administration Console. In-place upgrades require downtime proportional to your database measurement. Take a look at the precise period by upgrading a snapshot first. This methodology fits workloads that may tolerate downtime and like easier administration.
- Amazon RDS blue/inexperienced deployment – Amazon RDS blue/inexperienced deployments use PostgreSQL logical replication to take care of two synchronized environments. Improve the inexperienced (staging) surroundings utilizing Amazon RDS one-click improve, check your software completely, then change manufacturing site visitors with minimal downtime—usually underneath a minute. Though this methodology is straightforward to implement utilizing the console or AWS CLI, remember that DDL adjustments aren’t replicated and may break the replication course of.
- Logical replication – Amazon Aurora PostgreSQL-Appropriate and Amazon RDS for PostgreSQL help logical replication via pglogical. The method entails creating an preliminary snapshot of the writer database, copying it to the subscriber, then repeatedly replicating real-time adjustments. This strategy provides minimal downtime and steady replication however requires complicated preliminary setup and longer synchronization for big databases. Logical replication can’t replicate DDL, sequence, and enormous object operations.
- AWS Database Migration Service (AWS DMS) – AWS DMS helps Amazon Aurora PostgreSQL-Appropriate and Amazon RDS for PostgreSQL as each supply and goal databases, with change information seize (CDC) capabilities. Though AWS DMS allows minimal-downtime upgrades and steady replication, it doesn’t help all information sorts (like timestamp with time zone) and incurs further prices through the migration interval.
For detailed details about each in-place upgrades and varied out-of-place improve choices, confer with Improve your Amazon RDS for PostgreSQL or Amazon Aurora PostgreSQL database, Half 1: Evaluating improve approaches. It examines the benefits and drawbacks of every strategy.
Getting ready to improve
Earlier than upgrading, you must carry out the next actions:
- Assessment your present database configuration
- Take a look at the improve course of in a staging surroundings
- Validate software compatibility
- Create complete backup methods
If instant improve isn’t possible, Amazon RDS Prolonged Assist gives as much as 3 years of continued safety patches and bug fixes. RDS Prolonged Assist is a paid service offering essential safety and bug fixes for Amazon Aurora PostgreSQL-Appropriate and Amazon RDS for PostgreSQL main variations as much as 3 years past the usual help finish date. Pricing will increase primarily based on years elapsed since commonplace help expiration. Use the RDS Prolonged Assist window correctly to search out the appropriate improve path in your databases and purposes. This might help you streamline your improve course of in your manufacturing surroundings.
Conclusion
Upgrading from PostgreSQL v13 can provide you important efficiency enhancements, higher safety features, and extra environment friendly operations.
For detailed technical steering, seek the advice of the official AWS documentation and contemplate participating AWS help for complicated migration situations. You probably have AWS Enterprise Assist, your Technical Account Supervisor (TAM) can present skilled steering all through your improve journey. TAMs can join you with AWS specialists and supply focused sources to help a seamless improve course of.
Concerning the authors
