Skip to content

CONCEPT Cited by 1 source

MySQL version upgrade

Definition

A MySQL version upgrade is the operational primitive of moving a running MySQL database from version X.Y.Z to a later version. Upgrades come in two classes with very different risk profiles:

  • Minor version upgrades (e.g. 8.0.34 → 8.0.38) — security and bug-fix patches. Usually binary- compatible, rarely break application queries.
  • Major version upgrades (e.g. 5.7 → 8.0) — new features, deprecated syntax removal, auth plugin changes, sql_mode defaults changes, ~40 new reserved words. See [[concepts/ mysql-reserved-words-upgrade-break]] and the sibling [[sources/2026-04-21-planetscale-how-to-upgrade-from- mysql-57-to-80|2023-03-24 upgrade guide]] for the five-class upgrade-break taxonomy.

Two execution strategies

Morrison II (2024) canonicalises the two execution-strategy alternatives at the database tier:

Maintenance-window strategy

The default path on managed services: a planned downtime window during which the database is unavailable, the upgrade runs in-place, service is restored on the new version. Can be disruptive: "can be disruptive due to the downtime to apply the changes or due to undesired behavior changes in the database software."

Managed services offer two variants:

  • Automatic minor-version upgrades — applied during a configured maintenance window; low operator overhead but risk of unexpected behaviour changes.
  • Blue/green deployments — reduce downtime by running upgrade on a clone, then switching over; "lets you test the new version in an isolated environment that matches your current production environment". But "a labor-intensive task and requires significant planning."

Rolling-upgrade strategy

The alternative canonicalised by PlanetScale via rolling upgrades on Vitess on Kubernetes: upgrade tablets one at a time, let vtgate route around the unavailable tablet, complete the fleet-wide upgrade with no coordinated maintenance window. Verbatim: "PlanetScale engineers carefully verify that new versions are compatible with the system before they are applied. Once the changes are validated, they will be applied via rolling upgrades, taking advantage of the Vitess routing and Kubernetes technologies. This approach avoids the stress of having a disruptive maintenance window or further compatibility issues simply because Aurora is dropping support for version-specific features."

The central-validation-before-fleet-rollout shape ("our engineers carefully verify") is what makes rolling-upgrade-without-operator-validation safe at the vendor altitude — the customer outsources the compatibility audit to the managed service.

Seen in

  • sources/2026-04-21-planetscale-planetscale-branching-vs-amazon-aurora-bluegreen-deployments — Brian Morrison II (PlanetScale, 2024-02-02). Canonical wiki disclosure of the maintenance-window-vs-rolling-upgrade strategy choice at the MySQL database tier. Aurora positions blue/green as the downtime-reduction lever (still requires operator-side compatibility testing + planning); PlanetScale positions rolling upgrade with centralised version validation as the no-maintenance-window alternative.
Last updated · 378 distilled / 1,213 read