ClickHouse Support Lifecycle & Release History

How do ClickHouse release tracks shape cluster upgrade windows?

ClickHouse publishes stable releases and marks selected releases as LTS, while recommending that self-managed deployments adopt new minor releases frequently. The project does not describe a fixed, universal support duration for every minor branch, so treat the release labels and current upgrade documentation as the source of truth rather than assuming a branch has a guaranteed end date.

The key operational rule concerns mixed-version clusters: ClickHouse makes an effort to preserve a one-year compatibility window, including two LTS releases. This is guidance for versions running together during an upgrade, not a promise that every release receives patches for a full year. The same guidance recommends moving all cluster members to the same release promptly because version skew can slow distributed queries and cause retryable background-operation errors.

Minor releases are intended to avoid breaking changes while delivering bug fixes and sometimes security fixes. Release notes identify stable and LTS builds, and the self-managed upgrade guide advises reviewing those notes before changing binaries. In practice, choose a stable track that fits your change tolerance, use LTS when the slower release cadence better fits your maintenance process, and schedule upgrades based on the current release information rather than a presumed calendar.

Read the official self-managed upgrade guidance and the official ClickHouse release list for current labels and compatibility details.

What can stale MergeTree nodes mean for query and data safety?

An old ClickHouse node can miss later bug and security fixes, and a long-lived version gap between replicas can make cluster operations unreliable. This matters especially for MergeTree deployments: replication, background merges, mutations, and distributed reads depend on servers understanding compatible metadata and data-part formats.

Running different releases briefly during a rolling upgrade is expected, but a prolonged split is not a substitute for a supported operating plan. The upgrade guide warns that versions more than one year apart in a cluster may fail to work together; queries can return arbitrary errors, logs can accumulate warnings, and rollback may become impossible. These are compatibility concerns, not evidence that every older installation will immediately corrupt data.

Feature use adds another dimension. Experimental features can change incompatibly, and newer features or on-disk formats may limit downgrade options once data has been written. Before upgrading, review the intervening changelog entries for backward-incompatible changes, confirm the format and feature gates used by your tables, and test representative queries and replication behavior in a staging cluster. Preserve verified backups and a rollback plan that accounts for any new features already used.

The official changelog documents release-specific behavior changes; the upgrade guide explains version-skew limits.

What changes after a ClickHouse release leaves your upgrade window?

ClickHouse does not define one universal post-support state for every open-source release branch. When a deployment falls outside the documented compatibility window, do not assume it will receive fixes or remain safe to mix with newer cluster members; consult the current release notes and plan a move to a supported target.

A server does not stop accepting queries merely because it is old. Instead, the practical change is that known defects in that binary remain, later fixes are delivered in newer releases, and compatibility with more recent cluster members is no longer covered by the stated one-year guidance. Downgrade can also stop being viable after a workload has written data or enabled features the older binary cannot understand.

For a modest version gap, follow the official rolling-upgrade sequence: keep at least one replica for each shard available, upgrade replicas one at a time, wait for stability, then proceed with the remaining nodes. For a gap larger than the compatibility window, ClickHouse recommends an upgrade with downtime or an intermediate release that brings each step inside the window. Review changelogs across every skipped release and plan configuration changes before touching production.

Use the recommended upgrade plan as the operational reference. The applicable sequence depends on topology, storage, enabled features, and the target release.

How can you query the active ClickHouse server and replica versions?

Run ClickHouse's built-in version() SQL function to read the version of the server that executes the query. This checks the connected server rather than merely reporting which client binary is installed, which is useful when applications connect through a proxy or a load balancer.

SELECT version();

Run the query through clickhouse-client, the HTTP interface, or another SQL client. To compare versions across every replica in a configured cluster, query each replica and include its host name:

SELECT hostName(), version()
FROM clusterAllReplicas('default', system.one)
ORDER BY hostName();

This is a point-in-time check of the servers that answered. If the result set is incomplete, investigate cluster configuration and replica connectivity before concluding that every node is aligned. The official version() reference describes the function, and the clusterAllReplicas reference documents querying all replicas.