All Products
Search
Document Center

ApsaraDB RDS:Upgrade the major engine version of an RDS for PostgreSQL instance

Last Updated:Mar 10, 2026

ApsaraDB RDS for PostgreSQL supports major version upgrades to help you move from end-of-life versions to newer versions with improved performance, security, and features. You can choose from four upgrade solutions based on your downtime tolerance and rollback requirements.

Solution overview

Lower PostgreSQL versions gradually lose community support, which poses performance and security risks. RDS for PostgreSQL provides multiple major version upgrade solutions to help you benefit from new version improvements while minimizing upgrade risks.

A major version upgrade preserves the settings of the original instance, including whitelists, parameter settings, and extensions (except for extensions and parameters not supported by the new version). Additionally, encrypted RDS for PostgreSQL instances remain encrypted after the upgrade, and the encryption key remains unchanged.

Upgrade solution

In-place upgrade

Blue-green deployment

Zero downtime

Using DTS for data migration

Cutover

No cutover

Scenarios

You want the upgraded instance to be identical to the original instance. You can accept that the instance is read-only during the upgrade.

You want to retain the original instance. You can accept that the instance is read-only during the upgrade.

  • Upgrade rehearsal.

  • Running two application versions side by side.

Your business cannot accept long downtime.

  • Your business cannot accept long downtime.

  • The instance does not have many databases.

How it works

Uses pg_upgrade to upgrade the original instance to the target version. All metadata is preserved.

Creates a new instance from a backup, uses pg_upgrade to upgrade it, and automatically switches the original connection address to the new instance.

Creates a new instance from a backup and uses pg_upgrade to upgrade it.

Uses pg_upgrade to upgrade the original instance to the target version. Incremental updates are performed through native logical replication.

Manually creates a new RDS for PostgreSQL instance and uses asynchronous logical replication for data migration.

Advantages

The original instance configuration and billing information are completely preserved.

  • Automatically switches connection addresses.

  • Supports rollback to the original instance.

Provides an independent environment for upgrade verification without affecting the original instance.

  • Allows you to verify the new version before switching.

  • Supports manual switchover at a time of your choice.

  • Supports upgrading with read-only instances.

  • The original instance configuration and billing information are completely preserved.

  • Managed migration service with built-in orchestration.

  • Supports data validation.

Disadvantages

Does not support rollback to the original instance.

Does not inherit the billing information of the original instance.

None.

  • Does not support data validation or reverse data synchronization.

  • Logical replication has limitations. For example, all tables must have primary keys.

  • Switchover time increases with the number of sequence objects.

  • One migration task per database.

  • Manual switching of connection addresses is required.

Read-only time for original instance

Usually minutes.

Usually minutes.

None.

Usually seconds.

Usually seconds.

Cost

No upgrade cost.

New instance is pay-as-you-go.

New instance is pay-as-you-go.

No upgrade cost.

  • Cost of new RDS instance.

  • DTS instance cost.

Important

For the in-place upgrade mode, if the instance does not meet the recommended specifications during the upgrade, the system automatically upgrades the instance to the recommended specifications. This results in a minutes-level read-only state and a brief disconnection of approximately one second. We recommend that you resolve the specification alerts in the major version upgrade check report before upgrading.

Major version upgrade

Method 1: In-place upgrade

Method 2: Blue-green deployment

Method 3: Zero downtime upgrade

Method 4: Upgrade through DTS data migration

If you cannot use in-place upgrade, blue-green deployment, or zero downtime upgrade, or you want to perform data validation during the upgrade, you can use DTS for data migration.

  1. Create a new instance.

  2. Migrate data to the new instance.

  3. Release the original instance