VSHN Managed PostgreSQL
Problem
We need to specify how VSHN handles the major and minor upgrades of PostgreSQL by VSHN. This decision is not about upgrading StackGres, while related to this topic, it doesn’t have any customer impact.
So we need to decide two things:
-
How upgrades are handled
-
How we communicate with the customer about it
Requirements
-
Specification how we do upgrades
-
Specification when we do upgrades
-
Specification how customers should be informed
-
Specification when customers should be informed
Proposals
Upgrades
- Proposal 1
-
Automatic Minor and major upgrades
- Proposal 2
-
Automatic minor upgrade and manual major upgrades
- Proposal 3
-
Manual minor and major upgrades
Communication
- Proposal 4
-
Inform 3 months after EOL and then stop the instance
- Proposal 5
-
Inform 3 months after EOL and then keep the instances but unsupported
- Proposal 6
-
Inform 3 months after EOL and then delete the instance with enabled deletion protection
- Proposal 7
-
Inform 3 months after EOL and then force upgrade the instance
Decision
Upgrades
Proposal 2 and proposal 7
New minor updates will be tested on lab before we put them live. Each StackGres version supports specific major and minor versions of PostgreSQL, so it will need to be updated as well. After testing and updating StackGres, the new minor version will be rolled out in the next specified maintenance window for each cluster.
Force major upgrades won’t be to the most current release, but to the oldest still supported version. For example 12.x will be upgraded to 13.x even if 15.x is already available.
For the EOL information we take what PostgreSQL themselves say: www.postgresql.org/support/versioning/. StackGres will probably adhere to these policies as well.
Rationale
Upgrades
For minor upgrades the PostgreSQL docs say this:
For minor releases, the community considers not upgrading to be riskier than upgrading.
The general consent and best practices here is, that we upgrade to the latest available minor version as soon as possible.
However, major version upgrades often bring changes to internal structures and need migrations steps. PostgreSQL doesn’t maintain backwards compatibility, so there’s no way of going back, if an upgrade brings breaking changes. They can also contain new features and breaking changes that could have unintended side effects. Thus, it’s risky to automatically upgrade to the latest major versions.