10 Upgrade/migration bad practices

 

In this chapter

  • Skipping upgrade versions (and their release notes)
  • Not testing thoroughly before an upgrade or migration and what can happen
  • Accounting for differences between different database types and versions

Upgrading PostgreSQL is pretty easy, while migrating from another Relational Database Management System (RDBMS) to PostgreSQL may be slightly trickier. Both, however, are critical steps that require careful preparation and cannot be taken lightly. If something goes wrong, the upgrade or migration can result in performance issues, outages or even data corruption. Mistakes and oversights can come from misunderstanding the upgrade process for databases in general and PostgreSQL in particular

10.1 Not reading all release notes

We mentioned back in Chapter 7 that PostgreSQL offers great backward compatibility, and that you can generally count on code written for an old Postgres release still working fine on the latest version. For this reason, as well as a conscious decision on the part of the developers, Postgres doesn’t generally impose restrictions on upgrading. This means that you can usually skip versions provided there is no chasm between them, like upgrading from a release a decade older. For example, you could upgrade from version 13 to 16, and the upgrade path would usually be very reliable and worry-free.

10.2 Performing inadequate testing

10.3 Succumbing to encoding chaos

10.4 Not using proper BOOLEANs

10.5 Mishandling differences in data types

10.6 Summary