With the release yesterday of PostgreSQL 13, now is perhaps a good time to talk about when and how it should be deployed. We often get questions at such times like "When should I upgrade?" and "Should I switch my new planned deployment to the new release?"
The first thing to consider is this: you shouldn’t deploy any software you haven’t tested with. So unless you have been testing your app extensively with the Beta and Release Candidate builds of the new release, you shouldn’t deploy it immediately. Many deployments have no great reason to upgrade – they perform quite well and don’t need any of the new release features. We often see successful deployments that do not upgrade for years, that only apply the bug fix releases that the PostgreSQL community regularly produces, and that are always supposed to be drop in replacements, requiring far less testing and validation than a new major release.
When a new release comes out, the first thing to do is to look at the release notes. In particular, look at the section on Migration that’s always there. See if there is anything in there that might affect you. In many cases there won’t be, but you need to check just in case there is. Then look at the features. If there is something in there you need then you should plan for a deployment. That means you should do a full round of application updates if necessary, and then integration testing. Only then should you consider upgrading.
The PostgreSQL community produces bug fix releases for all supported release series (more or less any major release less than five years old) about every three months. In many cases, if you start your planning after a major release comes out, you will not be ready to deploy until the first bug fix release for it comes out. If, like many people and organizations, you prefer not to deploy .0 releases, then you can reasonably plan for a target deployment date of, say, four months after the release. PostgreSQL has generally been a lot more stable and reliable than some other software, so I think there less reason to trust its .0 releases than in the general case.
There will be cases where you really want to deploy the new release as soon as possible. Sometimes this is because of some spiffy new feature, but more often with existing deployments it’s because there is a performance improvement or a removal of some limitation that you have found irksome. In such cases it’s reasonable to deploy as soon as you can. But on no account neglect the integration testing I mentioned. "Haste makes waste" is a good motto for software management.
If you are an eager early adopter, then as the PostgreSQL community approaches a new release, keep an eye out for Beta releases. These usually appear around the middle of the year – this year Beta 1 was available in late May. This leads up to our normal release final release date around September. You can start testing with these releases. Of course, they shouldn’t be deployed in production, but if you don’t identify any issues in testing you will be ready to deploy the final release soon after it comes out. This is also one very good way to help the community – it helps us discover bugs before the release comes out, and also helps validate the releases.