Count where the work actually is. The 26.8 changelog section carries 21 backward-incompatible entries [5]. The five-release total, once the duplicated `http_max_fields` item is dropped, is 57 [4]. That leaves 36 in 26.4 through 26.7 [18], which is 63 percent of the breaking surface sitting in releases nobody plans to run as a destination, and whose notes therefore go unread [19].
One of those 36 sets the order of the whole plan. The guide separates hard stops from "test carefully" items: these are the "server won't start" and "you can't go back" class [22]. A server on 26.7 or later refuses to start if `insert_deduplication_version` is set to `old_separate_hashes` or `compatible_double_hashes`, and that entry appears nowhere in the 26.8 notes [12]. Remediation runs on the old server, not the new one. You bring up a release that still supports `compatible_double_hashes`, which writes both the legacy and the unified hash, and leave it running for at least the replicated dedup window before moving on [13]. The fix has to complete on a version that accepts a setting the target version rejects. That is what makes the plan a sequence.
The other start-time failure is the build target. The default x86 build moved from x86-64-v2 to x86-64-v3, which needs AVX2, BMI1, BMI2, F16C, FMA, LZCNT, MOVBE and XSAVE, in practice Haswell or Excavator and later [9]. Almost any x86 part made after 2015 clears that, but a hypervisor masking CPU flags fails the same check, and the binary simply does not run [10]. The test is one line per node, `grep -o 'avx2' /proc/cpuinfo | head -1`, and an empty result means that node needs the `amd64compat` build [11].
The 57 is the number that gets quoted. The roughly 70 settings that changed default value over the same span are the ones that will page you, and they appear on no backward-incompatible list at all [6]. Together that is about 127 items to read [20]. Treat the 57 as a count of upstream entries rather than a count of things that apply to your cluster: it was taken on 27 August 2026 against a section the changelog still marks FIXME [7], and three of 26.8's 21 entries carry unresolved TODO markers, one flagged "wait for the revert-of-revert" [14]. The author notes that marker sits where finished releases carry their presentation and video links, so it is reporting on the write-up rather than the code [8]. The 36 intermediate items are the settled part of the count, which also makes them the part you can start testing today.
Release status itself has two readouts that disagree. `version_date.tsv`, the file ClickHouse maintains of every released version and its date, printed "26.8 not released yet" at the time of writing [16]. The `clickhouse:lts` Docker tag meanwhile still resolves to 26.3.20.7 while 26.3.24.4 has shipped, four patch increments behind [15][21]. Since 26.7 collected five patch releases inside a month and 26.3 is already at 26.3.24, the guide's conservative line is to wait for roughly 26.8.3 before production [17]. That gap is the prep window, and it is long enough to do the 26.4-through-26.7 reading properly.
For this to collapse back into an ordinary upgrade with a long changelog, two things have to be true in your context: every host is post-2015 with unmasked flags, and nothing in your config has ever touched `insert_deduplication_version`. Both are cheap to establish, and both are cheaper to establish before anyone books a window.
