All Products
Search
Document Center

ApsaraDB RDS:RDS PostgreSQL major version upgrade

Last Updated:May 27, 2026

RDS PostgreSQL offers four major version upgrade solutions with different downtime and rollback trade-offs, helping you move from end-of-life versions to newer versions with improved performance, security, and features.

Solution overview

Lower PostgreSQL versions gradually lose community support, posing performance and security risks. RDS PostgreSQL provides multiple upgrade solutions to help you benefit from new versions while minimizing risk.

A major version upgrade preserves the original instance settings, including whitelists, parameters, and extensions (except those unsupported by the new version). Encrypted instances remain encrypted with the same key after upgrade.

Upgrade solution

In-place upgrade

Blue-green deployment

Zero downtime

Using DTS for data migration

Cutover

No cutover

Scenarios

You want the upgraded instance identical to the original and can accept read-only downtime during upgrade.

You want to retain the original instance and can accept read-only downtime during upgrade.

  • Upgrade rehearsal.

  • Running two application versions side by side.

Your business cannot tolerate long downtime.

  • Your business cannot tolerate 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, upgrades it with pg_upgrade, and automatically switches the original connection address to the new instance.

Creates a new instance from a backup and upgrades it with pg_upgrade.

Uses pg_upgrade to upgrade the original instance. Incremental updates are synchronized through native logical replication.

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

Advantages

Preserves original instance configuration and billing.

  • Automatic connection address switchover.

  • Rollback to the original instance.

Independent verification environment without affecting the original instance.

  • Verify the new version before switching.

  • Manual switchover at your chosen time.

  • Supports read-only instance upgrades.

  • Preserves original instance configuration and billing.

  • Managed migration service with built-in orchestration.

  • Supports data validation.

Disadvantages

No rollback to the original instance.

Does not inherit the original instance billing.

None.

  • No data validation or reverse synchronization.

  • Logical replication has limitations, such as requiring all tables to have primary keys.

  • Switchover time increases with the number of sequence objects.

  • One migration task per database.

  • Requires manual connection address switching.

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 in-place upgrade, if the instance does not meet recommended specifications, the system automatically upgrades its specifications. This causes a minutes-level read-only state and a brief disconnection of approximately one second. Resolve 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

Use DTS data migration if other upgrade methods are unavailable, or if you need data validation during the upgrade.

  1. Create a new instance.

  2. Migrate data to the new instance.

  3. Release the original instance