Upgrade strategies for Amazon Aurora PostgreSQL and Amazon RDS for PostgreSQL 12

Standard support for Amazon Aurora PostgreSQL-Compatible Edition and Amazon Relational Database Service (Amazon RDS) for PostgreSQL version 12 will conclude on February 28, 2025. For continued support and optimal performance, it’s crucial to plan your database upgrades. Refer to the official announcements for Aurora PostgreSQL and Amazon RDS for PostgreSQL for detailed guidance on upgrading your database systems. These resources provide essential information to help you navigate the upgrade process effectively and maintain the security and efficiency of your PostgreSQL environments.

• Amazon Aurora PostgreSQL 12.x end of standard support is February 28, 2025
• Amazon RDS for PostgreSQL 12 will reach end of standard support on February 28, 2025

Planning and testing are essential when upgrading to newer major versions of Aurora PostgreSQL and Amazon RDS for PostgreSQL, as these updates may introduce changes that affect existing application compatibility. Major version upgrades demand thorough evaluation to ensure seamless application functionality. While the upgrade process requires careful consideration, adopting the latest major releases brings significant benefits, including enhanced features, improved performance, and robust security improvements. To maximize these advantages while minimizing operational impact, it’s vital to conduct comprehensive assessment and preparation before implementing these upgrades.

In this post, we explore the end-of-life (EOL) timeline for Aurora PostgreSQL and Amazon RDS for PostgreSQL. We discuss features in PostgreSQL major versions, Amazon RDS Extended Support, and various upgrade strategies, including in-place upgrades, Amazon RDS blue/green deployments, and out-of-place upgrades.

The PostgreSQL community follows an annual major version release cycle, supporting each version for 5 years post-release. PostgreSQL 12.22, released on November 21, 2024, marks the final update for PostgreSQL 12, after which community-driven security and bug fixes cease. For Aurora PostgreSQL version policies and Amazon RDS for PostgreSQL release schedules, consult the official Amazon documentation:

• Release calendars for Aurora PostgreSQL
• Release calendars for Amazon RDS for PostgreSQL

Features available in PostgreSQL higher versions

The new features introduced in PostgreSQL higher versions enable applications to achieve better performance, stronger security, and reduced maintenance costs, while providing advanced capabilities that can give businesses a competitive edge in managing their data infrastructure. The following table summarizes the features available in PostgreSQL 13 and higher versions.

The availability of these features in Aurora PostgreSQL might vary depending on the specific version and release. Additionally, Aurora often includes custom enhancements and optimizations beyond the standard PostgreSQL features.

For the most up-to-date and detailed information on feature availability and version compatibility, refer to Amazon Aurora PostgreSQL updates.

Performance improvements with Graviton4

Aurora PostgreSQL higher versions support AWS Graviton3 based R7g database instances. Graviton4 instances provide up to 40% performance improvement and up to 29% price-performance improvement for on-demand pricing over Graviton3-based instances of equivalent sizes on Amazon Aurora databases, depending on database engine, version, and workload. Graviton4 processors represent AWS’s latest generation of custom-designed Graviton processors, built on the AWS Nitro System. These processors deliver significant advancements over their Graviton3 predecessors. Graviton4-based R8g AWS database instances are equipped with cutting-edge DDR5 memory technology, delivering exceptional memory bandwidth for rapid data access. R8g database instances provide enhanced networking capabilities with up to 50 Gbps bandwidth and up to 40 Gbps of bandwidth to Amazon Elastic Block Store (Amazon EBS).

Choosing a target engine version for upgrade

We advise upgrading all instances to PostgreSQL 16 or newer, though your specific application and business requirements should guide your target version selection. Proactively planning and executing the upgrade allows you to choose the most suitable version for your needs.

For a streamlined process, we suggest first upgrading to minor version 12.22 or later and applying any pending operating system (OS) maintenance. Then, upgrade directly to PostgreSQL 16 or beyond, bypassing intermediate major versions. This approach minimizes downtime and upgrade efforts. If PostgreSQL 16 isn’t with your application, consider alternatives like PostgreSQL 13, 14, or 15 based on your operational needs.

To identify available Aurora PostgreSQL target versions, you can use the AWS Command Line Interface (AWS CLI) with the following command:

aws rds describe-db-engine-versions --engine  aurora-postgresql --engine-version 12.22 --query "DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}" --output table
--------------------------
|DescribeDBEngineVersions|
+------------------------+
|      EngineVersion     |
+------------------------+
|  13.18                 |
|  14.15                 |
|  15.10                 |
|  16.6                  |
+------------------------+

You can use the AWS CLI as follows to find the target Amazon RDS for PostgreSQL versions:

aws rds describe-db-engine-versions --engine  postgres --engine-version 12.22 --query "DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}" --output table
--------------------------
|DescribeDBEngineVersions|
+------------------------+
|      EngineVersion     |
+------------------------+
|  13.18                 |
|  14.15                 |
|  15.10                 |
|  16.6                  |
|  17.2                  |
+------------------------+

PostgreSQL 12 upgrade options

There are three options to perform a major version upgrade: In-place upgrade, Amazon RDS blue/green deployment, and out-of-place upgrade. The in-place option upgrades the database on the existing instance or cluster. Blue/green deployment creates a fully managed staging environment using PostgreSQL community logical replication, which allows you to deploy and test production changes, keeping your current production database safer. An out-of-place upgrade uses an external database instance or cluster to accomplish the upgrade.

In-place upgrade

Both Aurora PostgreSQL and Amazon RDS for PostgreSQL support in-place automated upgrades, which use the pg_upgrade utility. This option is less complex than an out-of-place upgrade because it’s a feature of the managed service; AWS takes care of the heavy lifting and makes multi-version upgrades seamless.

In major version upgrades, Amazon RDS and Aurora complete the following steps:

1. Take a pre-upgrade snapshot. You can use this snapshot for rollbacks.
2. Shut down the instance and prepare it for the upgrade.
3. Use the pg_upgrade utility to run the upgrade job on the instance.
4. Take a post-upgrade snapshot. Networking is now reconfigured on the instance.

The downtime required for an in-place upgrade depends primarily on the size and number of the objects in the database. This can be determined by restoring a snapshot and upgrading it. Choose this option if your business can afford the downtime with the fewest administration tasks.

To learn more about major version upgrades, see Upgrading Amazon Aurora PostgreSQL DB clusters for Aurora PostgreSQL upgrades, and Upgrades of the RDS for PostgreSQL DB engine for Amazon RDS for PostgreSQL upgrades.

Amazon RDS blue/green deployment

Aurora PostgreSQL and Amazon RDS for PostgreSQL support blue/green deployments for version 11.1 and all higher major and minor versions. You can create a blue/green deployment to create a separate fully managed staging environment (green) that mirrors the production environment (blue). The following figure illustrates the deployment steps.

The staging environment clones your production environment’s primary database and in-Region read replicas. Blue/green deployment keeps these two environments in sync using PostgreSQL community provided logical replication. Use the Amazon RDS provided one-click in-place major version upgrades in your staging environment, then test your application in your staging environment (green). When you’re ready to switch, in as fast as a minute, you can promote the staging environment to be the new production environment with no data loss.

This process has the following advantages:

• You can stay current with database patches and system updates
• You can test major version database upgrades in a safe staging environment without affecting the production environment
• You can safely switch over through the use of built-in switchover guardrails

For more information, see Switching a blue/green deployment in Amazon RDS and Using Amazon Aurora Blue/Green Deployments for database updates.

Out-of-place upgrade

The following are the high-level steps for an out-of-place upgrade. Actual steps might vary depending on your environment and the synchronization method you choose.

1. Create a copy of the production database instance by using RDS snapshots or Aurora clones.
2. Upgrade the new instance to a later PostgreSQL version.
3. Configure continuous replication between the source and new upgraded instance by using one of the methods as discussed in the following sections.
4. During the cutoff window, after both the source and target database instances are in sync, point the application to the target database instance.

In the following sections, we discuss two replication options to perform an out-of-place upgrade.

Option A: Logical replication with pglogical

Aurora PostgreSQL and Amazon RDS for PostgreSQL version 12 and later support logical replication using pglogical. The process starts with taking a snapshot of the data on the publisher database and copying that to the subscriber. Then the changes on the publisher are sent to the subscriber as they occur in real time. For more information about using logical replication with Aurora PostgreSQL-, refer to Overview of PostgreSQL logical replication with Aurora.

This process has the following advantages and disadvantages:

• Downtime during the upgrade can be reduced
• It offers continuous replication
• It takes several steps to configure replication
• Initial synchronization on large databases might take more time
• As of this writing, you can’t use logical replication for some PostgreSQL data, including sequences, schema modification commands (DDL), and large objects
• There might be additional cost

Option B: AWS DMS with change data capture

Aurora PostgreSQL and Amazon RDS for PostgreSQL version 12 and later support AWS Database Migration Service (AWS DMS) with change data capture (CDC). You can used AWS DMS to perform live migrations with minimum downtime. For more information about upgrading with AWS DMS, see Upgrade your Amazon RDS for PostgreSQL or Amazon Aurora PostgreSQL database, Part 1: Comparing upgrade approaches.

This option has the following advantages and disadvantages:

• You can use this method to reduce downtime
• It offers continuous replication
• AWS DMS doesn’t support certain data types, such as timestamp with time zone
• You have to pay for AWS DMS for the duration it takes this upgrade project to complete

Choosing between the different upgrade approaches

The selection of upgrade strategy should balance business requirements for system availability against implementation complexity and resource requirements. You need to determine how much downtime your business can afford and the complexity of upgrade you’re willing to take on. The following table provides a summary of the different upgrade options and the trade-offs you need to consider.

Amazon RDS Extended Support

While we encourage database upgrade, Amazon RDS Extended Support is an option if you don’t want to upgrade right away. Amazon RDS Extended Support offers a valuable option for customers who need to continue running databases on a major version beyond the standard support end date for Aurora and Amazon RDS, at an additional cost. During the extended support period, Amazon RDS provides critical security updates and bug fixes, but no new features are introduced. Extended Support includes mandatory fees to cover the engineering costs of maintaining security patches and bug fixes for deprecated versions. Extended Support can maintain the deprecated engine version for up to 3 years after the community EOL date, with charges varying based on vCPU count, AWS Region, and the duration since standard support expiration. For Aurora PostgreSQL 12.x and Amazon RDS for PostgreSQL 12.x, these charges will commence from March 1, 2025, and will cease immediately upon upgrading the databases. New Aurora and RDS for PostgreSQL 12 instances can opt into this extended support by specifying ‘open-source-rds-extended-support’ for the –engine-lifecycle-support option when using AWS CLI commands to create database instances or clusters. For Extended Support eligibility, Aurora PostgreSQL databases will be automatically upgraded to either version 12.9 (LTS) or 12.22. For Amazon RDS for PostgreSQL, databases will be automatically upgraded to version 12.22. These versions are required – no other PostgreSQL 12.x minor versions can remain active during the Extended Support period.

Conclusion

Upgrading database version is not just about maintaining support, it’s about embracing a future of improved performance, enhanced features, and new possibilities. The journey from PostgreSQL 12 to 16 represents a significant evolution in database technology, one that can directly translate to better application performance, improved developer productivity, and enhanced user experiences.

Start planning your upgrade today, and set your databases—and your applications—on a path to a more powerful, efficient, and secure technology. For customers with AWS Enterprise Support, engage with your Technical Account Manager to get guidance or assistance on doing these upgrades. They have the resources, skills, and access to specialists to help with a smooth upgrade process. Additionally, AWS Enterprise Support offers engagements like AWS Countdown Premium to upgrade confidently with a specialist engaged early on for a successful rollout.

If you need assistance or have feedback, reach out to your usual AWS support contacts, or post a message in the AWS re:Post for Database.

For more information about the end of support for PostgreSQL 12, check out the video PostgreSQL 12 End of Standard Support for Amazon Aurora and RDS PostgreSQL.

About the authors

Vivek Singh is a Principal Database Specialist Technical Account Manager with AWS focusing on Amazon RDS for PostgreSQL and Amazon Aurora PostgreSQL engines. He works with enterprise customers providing technical assistance on PostgreSQL operational performance and sharing database best practices. He has over 17 years of experience in open-source database solutions, and enjoys working with customers to help design, deploy, and optimize relational database workloads on AWS.

Aditi Sharma is a Technical Account Manager at AWS. She has been with AWS for over 5 years and started her journey working as a Cloud Support Engineer in the RDS Databases team where she worked on various DB engines. Aditi is a Database and Security specialist. Prior to joining AWS, she was working as a Software Development Engineer in a Banking industry. Aditi hold Master’s in Management Information Systems and Bachelor’s in Computer Science Engineering. She is certified AWS Solutions Architect Associate, AWS Database Specialty, Certified Scrum Master and Certified Product Owner.

Manik Chopra is a Principal Technical Account Manager at AWS. He helps customers adopt AWS services and provides guidance in AWS cost and usage optimization. His areas of expertise include delivering solutions using Cloud Operations, Amazon QuickSight, Amazon Athena, and various other automation techniques. Outside of work, he enjoys spending time outdoors and traveling.

Nikhil Sehgal is a Technical Account Manager at AWS with over 8 years of industry experience, including more than 2 years at AWS. Previously, he was a Data Governance leader specializing in ETL and integration solutions across the Banking, Finance, Manufacturing, CPG, and Healthcare sectors. Currently, Nikhil supports AWS Strategic customers in their cloud adoption and operations. He holds a Master’s degree in Computer Science and is an AWS certified Solutions Architect, certified Database Specialist, and certified Data Analytics Professional.