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 | ||
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. |
| Your business cannot accept long downtime. |
|
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. |
| Provides an independent environment for upgrade verification without affecting the original instance. |
|
|
Disadvantages | Does not support rollback to the original instance. | Does not inherit the billing information of the original instance. | None. |
|
|
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. |
|
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.