Skip to content

CONCEPT Cited by 1 source

Rolling upgrade

Definition

A rolling upgrade is an upgrade idiom where the units of a fleet (containers, tablets, hosts, pods) are upgraded one at a time rather than all at once — each unit is drained, replaced with the new version, brought back into service, and only then is the next unit touched. At any given moment only a small fraction of the fleet is mid-upgrade, so the service as a whole remains available. This is structurally distinct from blue/green deployment, where the full fleet is replicated, upgraded on the idle side, then cut over via coordinated switchover.

Rolling upgrade is the canonical Kubernetes deployment primitive (kubectl rollout) and the Vitess primitive for tablet upgrades ("rolling upgrades to the tablets without taking down your database" — Morrison II, 2024).

Rolling vs blue/green

The two idioms solve the same problem ("replace a running fleet with a new version without downtime") with different trade-offs:

Axis Rolling upgrade Blue/green
Fleet duplication None (in-place) 2× for upgrade window
Cost during upgrade ~1× fleet cost ~2× fleet cost
Cutover shape Incremental (one unit at a time) Coordinated (all at once)
Rollback Pause / reverse the rollout Flip back to blue
Mid-upgrade state Mixed versions in fleet Clean separation
Switchover disruption Per-unit connection drain All-connections drop
Best for Stateless or weakly-stateful workloads Stateful workloads where coordinated cutover is safer

Rolling wins on cost + cutover smoothness — especially at the database tier where the blue/green cost-doubling is significant and switchover drops all connections. Blue/green wins on isolation — mixed versions can't interfere because the two environments are physically separate.

At the database tier on PlanetScale + Vitess, the rolling primitive is enabled by the tablet (a Kubernetes pod running mysqld with a vttablet sidecar) being the unit of replacement + vtgate proxy tier routing around unavailable tablets ("If a tablet goes down for any reason, our systems automatically reroute traffic to a functional tablet and allocate another tablet to replace the downed instance" — Morrison II, 2024).

Seen in

  • sources/2026-04-21-planetscale-planetscale-branching-vs-amazon-aurora-bluegreen-deployments — Brian Morrison II (PlanetScale, 2024-02-02). Canonical wiki framing of rolling upgrade at the database tier as the architectural alternative to blue/green. Verbatim: "we can seamlessly perform rolling upgrades to the tablets without taking down your database. This is based on our use of Vitess on Kubernetes. To make instance type changes, you'd select the new instance type, and our backend systems will do the rest. This allows your applications to continue to operate without being taken offline." Applied to instance-class resizing (no connection drop) and MySQL version upgrades ("applied via rolling upgrades, taking advantage of the Vitess routing and Kubernetes technologies").
Last updated · 378 distilled / 1,213 read