Timeline for PG version upgrade

Overview

Each year, we update our production database version to make use of the most recent features Postgres can provide.

It occurs that we don't have a proper documented process where we cover the necessary steps to anticipate an PG upgrade.

As the PG upgrade involves many teams, I propose we document a timeline of the steps we should keep track before updating the PG version for GitLab.com.

Teams involved

• groupdatabase operations: Responsible for the PG upgrade;
• groupdatabase frameworks: Responsible for handling database aspects at the application level;
• groupdeveloper tooling: Responsible for updating the developer tooling, like GDK, GCK etc;
• groupbuild: Responsible for shipping PG with Omnibus;
• ~"group::self managed": Responsible for shipping PG with GitLab Charts and Operator.

Goals

• Ensure we're delivering a flawless experience to customers;
• Ensure we're delivering quality;
• Ensure we're enabling developers with the updated tooling;
• Coordinate the steps between teams;

Deliverables

• Bringing peers together to gather necessary information that must anticipate an PG update;
• Document the timeline of events we must comply with before updating the PG version;