ClickHouse 26.8 LTS upgrade from 26.3 crosses 57 breaking changes

ClickHouse has announced version 26.8 LTS, and according to a dev.to analysis of the upstream changelog, upgrading from the previous long-term support release, 26.3, means absorbing 57 unique breaking changes spread across five releases rather than one.

The core problem, the post explains, is that an LTS-to-LTS move is never a single hop. Going from 26.3 to 26.8 passes through 26.4, 26.5, 26.6 and 26.7, and every backward-incompatible change in those intermediate releases applies too. Some of the riskiest items are not mentioned in the 26.8 notes at all.

The numbers behind the jump

The dev.to tally puts the intermediate releases at 6, 10, 10 and 11 breaking changes respectively, with 26.8 itself listing 21, the largest single count. The same releases also bring roughly 199 new features and 416 performance improvements.

The upstream changelog actually lists 58 backward-incompatible entries across the five releases, but one, an http_max_fields reduction in PR #103285, appears in both the 26.4 and 26.5 sections, apparently through a backport, leaving 57 unique changes. The author adds caveats: three of 26.8's 21 entries still carry unresolved TODO markers, one is flagged for a revert-of-revert, and the 26.8 section remains marked as in progress, so the count may yet move. All figures were counted on 27 August 2026.

Beyond the formal list, around 70 settings changed their default values across the five releases. Those entries never appear under a backward-incompatible heading, yet the post argues they account for much of the unexpected behaviour in practice.

Not fully shipped yet

As of 27 August 2026, 26.8 was announced but not fully released: the release branch was cut and versioned as v26.8.1.1-lts, but the tag and Docker images had not been published. The author suggests querying ClickHouse's version_date.tsv file for the definitive answer, and warns that Docker Official Images trail GitHub tags by several patch versions: the clickhouse:lts tag resolved to 26.3.20.7 even though 26.3.24.4 had already shipped.

Historically, LTS releases accumulate patches quickly (26.7 saw five within a month), so the post recommends waiting until roughly 26.8.3 before upgrading production clusters, and using the gap to prepare.

Three changes that can block the upgrade

The analysis singles out three items that can stop an upgrade entirely:

First, from 26.6 the default x86 build targets x86-64-v3 and needs AVX2 and related instruction sets, effectively Intel Haswell or newer and AMD Excavator or newer. Almost every x86 CPU after 2015 qualifies, but older machines or hypervisors that mask CPU flags will simply fail to run the binary; an amd64compat build targets plain x86-64 as a fallback. This change does not appear in the 26.8 notes, making it easy to miss.

Second, insert_deduplication_version has a mandatory migration order. If a config sets it to old_separate_hashes or compatible_double_hashes, a 26.7 or later server will refuse to start outright. The migration requires running a release that writes both the legacy and unified hashes for at least the deduplication window (one hour by default for replicated tables, or the equivalent insert count for non-replicated ones) before removing the setting. Separately, 26.6 redefined deduplication to operate on whole inserted blocks, so identical parts produced by different inserts, or reordered inserts of the same rows, are no longer cross-deduplicated.

Third, and in the author's view the most likely to trip teams up: from 26.7, S3 access originating from user SQL no longer resolves the server's own cloud credentials by default, whether from environment variables, IMDS or IRSA, instance profiles, AWS config files, role-based STS or GCP OAuth metadata. Restoring the previous behaviour requires setting both use_environment_credentials and s3_allow_server_credentials_in_user_queries to 1. The startup path is the nastier part: with s3_load_table_anonymously_if_credentials_restricted on by default, persistent S3 tables, S3Queue tables, dynamic S3 disks and affected DataLakeCatalogs load anonymously rather than aborting startup, so the server appears healthy and only fails at read time.

Silent changes to query results

Two 26.5 changes alter results without throwing errors. Date parsing defaults (date_time_input_format and cast_string_to_date_time_mode) moved from basic to best_effort, so loose strings such as 'Apr 15, 2020 10:30:00' now parse instead of being rejected, letting malformed input land rather than bounce. And CAST to DateTime or DateTime64 without an explicit time zone now preserves the source argument's time zone, changing displayed timestamps in existing queries.

Why it matters

LTS releases are what production users standardise on, and ClickHouse's cadence means every LTS jump silently bundles five releases' worth of breakage, including CPU requirements and startup refusals that never show up in the target release's own notes. The most dangerous changes here are quiet ones: S3 tables that load anonymously and only fail at read time, and parsing that accepts data it used to reject. Teams on 26.3 should audit CPU flags, deduplication settings and every S3 credential path now, and treat default-value changes as part of the breaking-change surface, not a footnote.