Deep PostgreSQL Thoughts: Valuing Currency

The PostgreSQL community released a set of minor versions on May 9th, 2024 — one for each of the supported “stable” major versions. Later that same day, Amazon RDS for PostgreSQL followed up with its own release announcement. It was the first time that we launched a minor version the same day as the community, which got me thinking about how important it is to maintain PostgreSQL currency.

I am not referring some interesting new cryptocurrency somehow based on PostgreSQL. And, although PostgreSQL is surely worth its virtual weight in gold, I don’t want to imply some tie to the gold standard either. Instead, what I aim to discuss is the importance of staying current with the latest and greatest PostgreSQL minor release version.

What are the best reasons to upgrade sooner rather than later? Conversely, what are the reasons to wait? Time to dive in.

Three Best Reasons to Upgrade Quickly

Intuitively, you know staying current is in your best interest. But let’s explore some concrete reasons you might want to stay as up to date as possible.

1. Known bugs get fixed

Looking at the most recent PostgreSQL community release announcement, it says: “This release fixes one security vulnerability and over 55 bugs reported over the last several months.” Even if you are not currently affected by one of those bugs, there are no guarantees that one or more of them will not bite you tomorrow.

2. Regressions are rare

The PostgreSQL minor versions are equivalent to what some database engines call “patches” and never contain new features — by longstanding policy they only fix bugs. In fact, the official policy says “Minor releases only contain fixes for frequently-encountered bugs, low-risk fixes, security issues, and data corruption problems. The community considers performing minor upgrades to be less risky than continuing to run an old minor version.” Because of this policy, regressions in minor version updates are extremely rare. I can only recall a few in over two decades of closely following and participating in PostgreSQL development.

3. Compliance

Many organizations must meet compliance directives, or at least have policies that aspire to meet some best practice. Some examples:

• CIS Benchmark – The CIS Benchmark for PostgreSQL specifically says “One of the best ways to ensure PostgreSQL security is to implement security updates as they come out, along with any applicable OS patches that will not interfere with system operations.”
• CISA Binding Operational Directives – According to “BOD 19-02: Vulnerability Remediation Requirements for Internet-Accessible Systems”:
  • Critical vulnerabilities must be remediated within 15 calendar days of initial detection.
  • High vulnerabilities must be remediated within 30 calendar days of initial detection
• An even more strict requirement is handed down by the German “Federal Office for Information Security (BSI)” in its Cloud Computing Compliance Criteria Catalogue – C5:2020 which says under “OPS-22 Testing and Documentation of known Vulnerabilities”:
  Available security patches are applied depending on the severity of the vulnerabilities, as determined based on the latest version of the Common Vulnerability Scoring System (CVSS):
  • Critical (CVSS = 9.0 – 10.0), 3 hours;
  • High (CVSS = 7.0 – 8.9), 3 days;
  • Average (CVSS = 4.0 – 6.9), 1 month; and
  • Low (CVSS = 0.1 – 3.9), 3 months

Reasons Not to Upgrade

Of course there is always a flip side, isn’t there? Some considerations that give pause are:

1. Restart required

There is no way currently to replace the PostgreSQL binary with a newer version without restarting the daemon, causing a brief service interruption. This is typically mitigated in high availability clusters, for example by upgrading replicas first and then failing over and redirecting queries in order to update the original primary node.

2. Fear, uncertainty, and doubt

Face it, when it comes to production workloads, the old adage “if it ain’t broke, don’t fix it” comes to mind. But as noted above, PostgreSQL minor updates are more likely to fix real problems from which you may suffer, than to cause you new forms of grief.

3. Priorities

Maybe you have bigger fish to fry and updating PostgreSQL is not at the top of your list. For sure if you don’t have a burning need to upgrade PostgreSQL because it is working well for you, and other services are in less enviable positions, then by all means work your priorities. But at some point you will have to pay the piper, so don’t wait too long. Remember, unless you have extended support from your service provider, nominal support horizon for PostgreSQL major versions is 5 years. And there is that possibility that a latent issue that has already been fixed will bite you you-know-where. Get both minor and major upgrades on your maintenance schedule, and get them done.

Summary

The bottom line is that generally speaking, PostgreSQL currency buys you fewer bugs, higher security, and comes with relatively low risks. Quarterly minor releases are an important part of maintaining currency with the latest and greatest PostgreSQL features and fixes. Upgrading to the latest minor version can provide several key benefits, including resolving known issues, minimizing the risk of regressions, and ensuring compliance with industry standards and regulations. While there are some considerations around the need for a service restart and potential concerns about disrupting a stable production environment, the overall benefits of staying current with PostgreSQL minor releases typically outweigh the downsides. Organizations should prioritize keeping their PostgreSQL deployments up-to-date as part of their regular maintenance and security practices. Let your conscience be your guide, but my humble recommendation is to keep up and sleep well!