As the PostgreSQL community stops maintaining lower versions (such as 9.4 and 10), continuing to use these lower versions poses risks. If you need to upgrade your RDS PostgreSQL instance from a lower version to a higher version, or want to use new features in higher versions, we recommend that you perform a major version upgrade.
Solution overview
The PostgreSQL community regularly releases major versions with improved functionality and performance. Lower versions gradually lose support, posing performance and security risks. To help you benefit from new version improvements while reducing upgrade risks, RDS PostgreSQL supports major version upgrades.
The major version upgrade feature of RDS PostgreSQL preserves the settings of the original instance after the upgrade, including whitelists, parameter settings, and plugins (except for plugins and parameters not supported by the new version). Additionally, encrypted RDS PostgreSQL instances remain encrypted after a major version 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. |
|
Implementation principle | Uses pg_upgrade to upgrade the original instance to the target version. All metadata is preserved. | Restores to a new instance and uses pg_upgrade to upgrade it to the target version. The original connection address is automatically switched to the new instance. | Restores to a new instance and uses pg_upgrade to upgrade it to the target version. | 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 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 based on the old 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 will automatically attempt to upgrade using the recommended specifications. This will result in a minutes-level read-only state and an additional one-second transient connection. We recommend that you address the alerts regarding instance specifications in the major version upgrade check report before upgrading.
Major version upgrade
Method 1: Upgrade the major version through in-place upgrade mode
Method 2: Upgrade the major version through blue-green deployment mode
Method 3: Upgrade the major version through zero downtime mode
Method 4: Upgrade through DTS data migration
If you cannot upgrade using the above three methods, or you want to perform data validation during the upgrade, you can upgrade through DTS data migration.