VSHN Managed PostgreSQL


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


  • Specification how we do upgrades

  • Specification when we do upgrades

  • Specification how customers should be informed

  • Specification when customers should be informed



Proposal 1

Automatic Minor and major upgrades

Proposal 2

Automatic minor upgrade and manual major upgrades

Proposal 3

Manual minor and major upgrades


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



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.



For minor upgrades the PostgreSQL docs say this:

For minor releases, the community considers not upgrading to be riskier than upgrading.
— https://www.postgresql.org/support/versioning/

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.


Keeping unsupported instances around may give us issues with StackGres. So we should upgrade them as soon as possible, so we’re not blocked for StackGres upgrades.