All posts
ClickHouse® 26.10 Release: Features, Changes & Upgrade Guide

ClickHouse® 26.10 Release: Features, Changes & Upgrade Guide

October 27, 202610 min readMohamed Hussain S
Share:

The ClickHouse 26.10 release update, dated October 22, 2026, is a substantial release. It introduces:

  • 60 new features and 41 experimental features
  • 37 backward-incompatible changes
  • 225 performance improvements
  • 739 bug fixes
  • Lightweight updates reaching general availability
  • Query-aware workload scheduling and per-workload spilling
  • Tighter security defaults and stricter validation

This release matters for production users mainly because of the validation and security changes: several existing objects and configurations can stop loading after the upgrade, so it is worth reading the breaking changes before you plan a rollout.

Below is a structured breakdown based on the official 26.10 changelog. It was written on release day, while the changelog was still being finalised, so individual entries may be refined.

Breaking Changes in ClickHouse 26.10

The changelog lists 37 backward-incompatible changes. These are the ones most likely to affect existing deployments.

Legacy Analyzer Fully Removed

enable_analyzer has been obsolete since 26.9, and in 26.10 the pre-analyzer query analysis is removed entirely. A server now also uses the analyzer for queries that another server sends, so in a mixed-version cluster an initiator older than 26.10 can fail with NOT_FOUND_COLUMN_IN_BLOCK.

This mainly affects clusters upgrading from 26.8 or earlier that run with enable_analyzer = 0: set it to 1 on every server before upgrading any of them. A cluster already on 26.9 cannot have the analyzer disabled.

Named Collection Overrides Need a New Privilege

Overriding a key stored in a named collection now requires SHOW NAMED COLLECTIONS SECRETS on that collection.

Existing tables that override a NOT OVERRIDABLE key cannot be loaded after the upgrade, and the server does not start. Recreate such tables without the override, or make the key overridable, before upgrading.

Stricter Validation of Configuration and Objects

Several things that used to be silently accepted are now rejected:

  • Unknown elements in disk definitions fail with UNKNOWN_ELEMENT_IN_CONFIG
  • Remote, RemoteSecure and Cluster databases with an empty remote database name no longer load
  • Columns whose type names the state of a window-only function, such as AggregateFunction(rank), no longer attach
  • Data written with the experimental ZXC codec by earlier versions cannot be read (CANNOT_DECOMPRESS)

Check for these before upgrading rather than after.

seccomp Enabled by Default in Packages and Docker

The server can now install a seccomp system call filter, and the shipped config.xml sets it to trap. A server running in a sandbox that refuses the seccomp system call must switch the setting to log or disabled before the upgrade.

HTTP URL Paths Routed by Default

Table and database access through URL paths now works without extra configuration:

curl http://localhost:8123/my_db/my_table.csv

Previously every path that was not a configured handler returned 404. Reverse-proxy rules or access checks that assumed that should be reviewed. To restore the old behavior:

<http_allow_path_requests>0</http_allow_path_requests>

Query Semantics Tightened

  • arrayCount now returns UInt64 instead of UInt32
  • arrayJoin is lowered to an ARRAY JOIN step, so non-deterministic functions such as rand next to it are evaluated once per output row
  • accurateCast from strings to a Nullable type now throws instead of returning NULL
  • SummingMergeTree ... FINAL no longer removes rows whose summed columns are all zero
  • With skip_unavailable_shards = 1, a read fails if every shard was skipped, instead of returning an empty result

system.metric_log Uses the Bucketed Schema

All metrics are now stored in a single Map column, with per-metric ALIAS columns so existing queries keep working. On upgrade the old table is renamed to metric_log_0, so tooling that reads system.metric_log directly will not see older rows without a merge. Add <schema_type>wide</schema_type> to keep the previous schema.

MySQL Connections Verify the CA

MySQL connections that set ssl_ca now verify the certificate chain and host name. Connections that used to succeed against a certificate signed by a different CA, or one that did not list the host used, now fail.

Major New Features in ClickHouse 26.10

Lightweight Updates Are GA

The UPDATE statement and patch parts move from Beta to generally available, and enable_lightweight_update is now in the production feature tier.

Query-Aware Workload Scheduling

Workloads gain a scheduler setting with four modes:

  • fifo (default)
  • fair, weighted fair queueing
  • las, least-attained-service
  • priority, using the workload_priority query setting

Workloads can also set max_memory_before_spill and max_memory_to_spill_ratio to make ORDER BY, GROUP BY, IN, DISTINCT and JOIN with grace_hash spill to disk under memory pressure.

IN Subquery Sets Spill to Disk

Sets built for IN with a subquery or table now spill to disk by default once memory usage exceeds half of the available memory (max_bytes_ratio_before_external_set = 0.5; the absolute max_bytes_before_external_set stays 0). The feature is generally available.

Function Composition and Placeholders

New f | g operator and _, _1, _2 placeholders:

SELECT arrayMap(plus(_, 1) | multiply(_, 2), [1, 2, 3]);  -- [4, 6, 8]

Trino Dialect Elements and a Block Nested Loop Join

TRY_CAST, the ARRAY[...] constructor and Trino function aliases such as starts_with and regexp_like now work in regular ClickHouse SQL. The Kusto (KQL) and Trino dialects were promoted from experimental to beta.

A JOIN with an arbitrary ON condition and no equality between the tables now runs as a block nested loop join instead of failing. It is as slow as a CROSS JOIN with a filter, and is controlled by allow_block_nested_loop_join.

Query Cache on Disk

Query cache entries can be stored in a preconfigured filesystem cache. This gives entries more space, lets them survive restarts, and with a distributed filesystem cache lets servers share them.

New Database Engines and Replication Conversion

  • Cluster database engine: access to the tables of a configured cluster database
  • Overlay database engine: a union view over several existing databases
  • ATTACH TABLE ... AS REPLICATED converts a MergeTree table in an Ordinary database to ReplicatedMergeTree

OAuth/OIDC Login and Web UI Notebook Mode

clickhouse-client --login can authenticate against OAuth/OIDC identity providers, and the Web UI (/play) gains a notebook mode where each query can be followed by further cells.

Performance Improvements in ClickHouse 26.10

This release contains 225 performance entries. The optimizer changes in the first three sections below are enabled by default.

GROUP BY Top-K

GROUP BY key ORDER BY key LIMIT n now shares its top-K boundary with the MergeTree reading step and between aggregation threads, so rows that cannot make the result are skipped early.

Join Improvements

  • JOIN runtime filters now prune granules on the probe side
  • full_sorting_merge joins of two MergeTree tables on a prefix of their primary keys now run as independent merge joins over key ranges on all threads (query_plan_join_shard_by_pk_ranges, on by default). In the release call's example (200M ⋈ 50M rows), the join dropped from 9.1 s to 0.78 s, and from 1.3 GB to 256 MB of memory
  • Outer-to-inner join conversion considers filters further up the plan

PREWHERE for FINAL Queries

optimize_move_to_prewhere_if_final is now on. Only deterministic conditions that depend on the sorting key alone are moved, so the FINAL result is unaffected.

Lower Memory for Large Hash Tables

Large hash tables used for GROUP BY, uniqExact and JOIN now use up to two times less memory, and aggregation with many keys is faster on many threads. In the release call's examples, a GROUP BY with 10M keys over 1B rows on 48 threads went from 24.7 GB to 16.3 GB (1.55 s to 1.28 s), and uniqExact over 100M distinct values from 13.5 GB to 4.6 GB (1.33 s to 0.31 s).

String Filtering During the Scan

LIKE, position, startsWith and endsWith conditions on String columns are pushed from PREWHERE into the column scan, so non-matching values are not copied. This is controlled by apply_string_filters_during_scan, now on by default, and applies to MergeTree and Parquet pages. In the release call's example, the peak memory of WHERE URL LIKE '%google%' fell from 275 MB to 5 MB.

Top-K Filtering for Parquet

ORDER BY column LIMIT n over Parquet files filters out rows that cannot enter the top-K inside the reader, and skips whole row groups using their min/max statistics (use_top_k_dynamic_filtering). The release call showed a query over file('hits.parquet') going from 0.37 s to 0.077 s, and the same applies when Parquet is read through s3, url, azureBlobStorage, hdfs and Iceberg tables.

Function-Level Speedups

  • hasAny on integer arrays: up to 15x faster
  • CAST of strings to Nullable(Bool): up to 7x faster with 8 threads
  • uniqCombined state merges: up to 6x faster
  • LIKE, ILIKE and match with a non-constant pattern: up to 5x faster with 8 threads
  • least, greatest and clamp on nullable or multi-argument inputs: 3-7x faster

Narrower Query Pipelines Under High Load

use_concurrency_control_for_max_threads is now on. When max_threads is not set explicitly, a query is planned with its fair share of CPU slots rather than all CPU cores, which raises throughput and lowers memory use under many concurrent queries, while a query on an idle server still uses all cores. In the release call's example (10 clients cycling over ClickBench on 96 cores), p99 memory fell from 9.33 to 7.67 GiB and CPU time per query dropped 15%.

Observability & Diagnostics Improvements

  • New system.query_log columns describing what a query executed, including used_number_of_joins, used_join_algorithms and used_join_kinds
  • traceView table function that renders an OpenTelemetry trace as a call tree
  • OpenTelemetry spans for each remote shard read in distributed queries
  • last_error_symbols and last_error_lines in system.errors
  • New profile events for network activity (DNSRequests and others)

Data Lake & Format Improvements

  • Parquet VARIANT columns read into Dynamic, and Iceberg variant support
  • SQLite format for reading and writing
  • The postgresql table function and table engine can connect to another ClickHouse server over the PostgreSQL protocol
  • plain_rewritable disks such as s3_plain_rewritable support hard links through the new enable_hard_links setting (off by default), which enables ALTER operations and mutations on MergeTree tables stored there without copying data

Stability Improvements

The ClickHouse 26.10 release update includes 739 bug-fix entries, along with many more responsive cancellation paths: KILL QUERY, max_execution_time and DROP TABLE now interrupt more kinds of long-running work promptly.

Upgrade Checklist

Before upgrading:

  1. If you are upgrading from 26.8 or earlier, set enable_analyzer = 1 on every server that still has it at 0 before upgrading any of them.
  2. Check named collection overrides and SHOW NAMED COLLECTIONS SECRETS grants.
  3. Check for unknown disk elements, empty Remote/Cluster database names, window-function states in column types, and ZXC-coded columns.
  4. Confirm your sandbox allows the seccomp setting, or set it to log or disabled.
  5. Review HTTP path routing and the AI function quotas, which now default to no limit.
  6. Update dashboards that read system.metric_log.
  7. Re-test queries using arrayJoin, accurateCast, SummingMergeTree ... FINAL and skip_unavailable_shards.
  8. Verify MySQL sources: the configured CA must sign the server certificate and the certificate must list the host used.

Conclusion

The ClickHouse 26.10 release update is a large release.

Key themes:

  • Lightweight updates reach general availability
  • Query-aware workload scheduling and per-workload spilling
  • Stricter validation and tighter security defaults
  • Spilling for IN sets by default
  • A broad set of join, aggregation and function-level performance gains

For production environments, the performance and workload-control improvements are substantial, but the validation changes mean existing tables, databases and configurations should be checked before the upgrade. If you skipped 26.9, note that this article covers 26.10 only; 26.9 adds 17 backward-incompatible changes of its own.

References

Official ClickHouse Changelog

ClickHouse Release 26.10 Call (presentation)

Share: