Supporting the current PostgreSQL stable version
There might be a better place (or multiple) for this issue. For it will affect multiple aspects of GitLab, we start with the general idea and guideline here.
Briefly describe the update
Currently, our products PostgreSQL support as well as the production versions we use for GitLab.com are multiple major versions behind the current stable release. Supporting and using the current PostgreSQL stable version has multiple advantages.
- Less engineering efforts and cost saving — Currently, we are on version
12
, stable is15
. Our current procedure is to upgrade to any version in between,12 -> 13
,13 -> 14
,14 -> 15
. Each of these upgrades requires significant testing and orchestration as well as a maintenance windows. Upgrading from versionA -> A+x
has the same complexity class regardless ifx = 1
orx > 1
. In this situation we could save factor 2-3 in engineering time. - Better performance — Logical replication, partitioning, compression, index bloat reduction, as well as increased parallelization are just some topics that were heavily worked on over the last PostgreSQL releases 14,15. These improvements will help with the workload of GitLab.com as well as on other large instances. This is a general pattern for all older version will only receive bug fixes, not performance improvements or new features.
- Supporting modern platforms — When running PostgreSQL on k8s operators are used. These are primary developed and therefor mostly tested for the current or upcoming stable version. Even if older versions are (partially) supported the ecosystem here orientates towards the current.
- End of Life — It is preferred to run the current stable version, but even if it's decided by an operator to not upgrade, starting with the most recent version gives a much higher time of operation before the used version reaches end of life. PostgreSQL receives 5 years support. The current release can therefor be used safely for up to 5 years. If the used major version, at the time of installation, is already 3 years old, upstream support will end within the next 2 years. For long term support setups, utilizing the full 5-year lifecycle is beneficial.
There will be good reasons why we are not supporting the current version already, this ticket aims to find the stakeholders, explore the reasoning and start the process of deciding on a strategy regarding the supported versions.
Proposed change (Draft)
New GitLab releases will support the current stable version of PostgreSQL at the time of release. During development the official beta packages are used to test the compatibility in advance, if the anticipated PostgreSQL version is not released jet.
The most recent stable version of PostgreSQL should be used for our own infrastructure. Rolling it out after a reasonable delay ensures that each major release is sufficiently tested by thousands of users before, while also enabling GitLab.com to benefit from new features and performance improvements reasonable soon after they are released.
The targeted delay is 12 months
.