Standard support for Amazon Aurora PostgreSQL-Compatible Edition and Amazon RDS for PostgreSQL version 13 will conclude on February 28, 2026. This impending deadline compels database administrators to take prompt action. With PostgreSQL 13 being deprecated by the community in November 2025, it will no longer receive bug fixes or security patches, thereby exposing systems to potential vulnerabilities. AWS recommends upgrading to newer versions, such as 16 or 17, which promise significant performance enhancements, improved security, and advanced features, as outlined in a recent post on the AWS Database Blog by Abhimanyu Tomar, Sachin Murkar, and Niraj Jani.
Performance and Security Enhancements
The advantages of upgrading to newer releases are substantial. PostgreSQL 17, for instance, boasts up to twice the write throughput due to improved Write-Ahead Logging (WAL) processing and consumes 20 times less memory during vacuum operations. Version 16 introduces pg_stat_io, providing detailed I/O statistics, while version 14 incorporates a vacuum emergency mode to prevent transaction ID wraparound. Aurora-specific enhancements in version 14.9 and later, such as tiered caching that extends up to five times the instance memory on I/O-Optimized clusters, can lead to up to eight times faster query latency and a 30% reduction in costs for large datasets, according to AWS documentation.
Security improvements are equally noteworthy. Version 14 introduces roles like pg_read_all_data and pg_write_all_data to simplify access control, while version 15 revokes the PUBLIC creation permission on the public schema. Major upgrades in logical replication include automatic slot synchronization during failover in version 17 and support for parallel apply with multiple background workers in version 16.
Navigating Breaking Changes
Transitioning between major versions necessitates careful examination of catalog changes. In PostgreSQL 17, the pg_stat_bgwriter view loses the buffers_backend and buffers_backend_fsync columns, which are replaced by the new pg_stat_checkpointer view. Additionally, the pg_stat_progress_vacuum view renames max_dead_tuples to max_dead_tuple_bytes and introduces new columns such as indexes_total. Configuration parameters also evolve; for example, the default for password_encryption shifts from md5 to scram-sha-256 in version 14, while version 15 adds support for wal_compression using zstd and lz4. AWS authors emphasize, “Review all changes carefully—some may break applications relying on deprecated views or parameters.”
Views like pg_stat_activity gain a query_id column that requires compute_query_id in version 14, while pg_database adds dathasloginevt and renames daticulocale to datlocale. These modifications, detailed in AWS release notes, necessitate thorough pre-upgrade testing in staging environments to identify compatibility issues early on.
Extensions must also be verified, as most do not auto-upgrade. For instance, logical replication slots using pglogical need to be dropped before major upgrades, as noted in the Amazon RDS User Guide.
In-Place Upgrades for Simplicity
The most straightforward approach is to perform an in-place major version upgrade via the AWS Console or CLI, utilizing pg_upgrade under the hood. Downtime will vary based on database size, so AWS recommends conducting snapshot-based testing beforehand. The AWS Database Blog describes the “direct upgrade of the DB instance” as suitable for workloads that can tolerate planned outages. For Aurora clusters post-version 13.7.3, zero-downtime patching (ZDP) minimizes disruptions during minor upgrades, as outlined in the Aurora User Guide.
To check valid upgrade targets, the CLI command aws rds describe-db-engine-versions –engine aurora-postgresql –engine-version 13.x –query ‘DBEngineVersions[].ValidUpgradeTarget[?IsMajorVersionUpgrade == `true`].{EngineVersion:EngineVersion}’ can be utilized. From version 13, paths lead to 14, 15, 16, or 17, although direct upgrades to 17 may necessitate intermediate steps for certain extensions, such as rdkit.
Preparation involves validating instance classes, parameter groups, and dropping replication slots. After the upgrade, extensions can be re-enabled with ALTER EXTENSION UPDATE.
Blue/Green Deployments Minimize Risk
For near-zero downtime, Amazon RDS Blue/Green deployments excel by employing PostgreSQL logical replication to synchronize the production (blue) environment with a staging (green) environment. The green environment can be upgraded with a single click, allowing for application testing before switching traffic in under a minute. This feature is supported from Aurora PostgreSQL version 13.12 onward, as discussed in previous AWS blogs on version 12 strategies. However, caution is advised; “DDL changes aren’t replicated and can break the process,” warns the January 2026 post, suggesting that schema alterations should be avoided during synchronization.
Users on Reddit’s r/aws community have reported parameter adjustments, such as enabling rds.logical_replication=1 prior to creating blue/green deployments from version 13.18 to 17.5. This managed approach automates cutovers, making it ideal for maintaining production continuity.
For global databases, the upgrade process becomes more complex; the global cluster should be upgraded first using the command aws rds modify-global-cluster –allow-major-version-upgrade, as per AWS re:Post guidance.
Replication and DMS for Complex Migrations
Logical replication through pglogical provides flexibility: snapshot the publisher, seed the subscriber, and then replicate changes continuously. The advantages include minimal downtime, but it does not support DDL, sequences, or large objects. Initial synchronization times can be challenging for large databases, although parallel apply in version 16 helps to expedite this process.
AWS DMS facilitates homogeneous migration with Change Data Capture (CDC) for both Aurora and RDS PostgreSQL. While it supports ongoing replication, it does not cover certain types, such as timestamp with time zone. “For large-scale migrations requiring schema changes,” the AWS post recommends DMS, linking to its comprehensive documentation.
Extended Support is available, providing up to three years of security patches for a fee via the RDS console opt-in. However, AWS encourages proactive upgrades to avoid additional costs and to take advantage of innovations, such as 256 TiB storage in Aurora 17.5 and beyond.
Testing and Best Practices
Universal best practices include replicating production environments in staging, conducting load tests, and validating queries against new catalogs. Post-upgrade monitoring can be accomplished using pg_stat_io and pg_wait_events in version 16 and later. AWS CLI queries can confirm upgrade paths, while documentation outlines pre-checks such as verifying template database states with the command SELECT datname, datistemplate FROM pg_database to ensure that template0 and template1 are marked ‘t’.
Recent minor releases, including Aurora PostgreSQL 17.6 and 16.10, highlight ongoing progress, featuring shared plan caches and improvements to Global Database functionality. Organizations like Netflix have reported performance boosts of up to 75% after migrating to Aurora, as detailed in AWS case studies.
For complex setups, engaging AWS Support is advisable. Thorough planning is essential to ensure seamless transitions before the February deadline.
