The Keycloak Upgrade Ledger

Every upgrade we have rehearsed, with the environment stated and the clock running.

2026-08-31 · run 2026-08-31-matrix-remaining-26.7.3

remaining version-matrix paths at 26.7.3

Results

All direct (unstepped) hops to 26.7.3, Postgres 16, typical profile, 1,000 users, single container, laptop.

PathTimeIndex auditRealm
25.0.6 → 26.7.320s119/1191,000 users intact
24.0.5 → 26.7.320s119/1191,000 users intact
22.0.5 → 26.7.320s119/1191,000 users intact
26.6.4 → 26.7.317s119/1191,000 users intact

Findings

  1. Every source version goes direct to 26.7.3 — no stepping needed across the 25→26 major boundary, the 24→26 two-major jump, or the 22→26 three-major jump. Liquibase applies the pending changesets in one pass. This is the same shape as the 21.1.2 → 26.7.1 direct hop already recorded.

  2. Migration duration is flat across the span (~17–20s) — it tracks the changeset count that actually runs, not the version distance. Confirms the lab's earlier finding that "duration against a stated dataset size" is the right frame, and the causal variable is the changeset set.

  3. The 26.6.5 / 26.6.6 container images are not published. GitHub carries the 26.6.5 and 26.6.6 tags, but quay.io/keycloak/keycloak stops the 26.6 line at 26.6.4. 26.6.5 is the patch the 2026-08-06 advisory batch names as the 26.6-line fix, so a customer pinned to the 26.6 line cannot pull that fix as a container image — they must go to 26.7.x. This belongs in the runbook's version-availability note (the lab already has one for the 22.0.x line ending at 22.0.5).

← Back to the Ledger