ClickHouse 26.9 Adds Incremental Refreshable Materialized Views, Time-Limited CREATE TOKEN Credentials and Boundary-Based LIMIT
ClickHouse 26.9 ships 56 new features, adding APPEND INCREMENTAL refreshable views for Iceberg, CREATE TOKEN credentials, LIMIT AFTER/UNTIL, and DISTINCT disk spilling.
Overview
ClickHouse has released version 26.9. According to the ClickHouse release post, the release “contains 56 new features 🍁 135 performance optimizations 🍎 and 464 bug fixes 🐿️.” The 26.9 release call slides list the same three counts. The previous spring release was covered in ClickHouse 26.5.
What We Know
Incremental refreshable materialized views
The release post says ClickHouse 26.9 adds APPEND INCREMENTAL to refreshable materialized views, so that instead of scanning the entire source table on every refresh, ClickHouse processes only the rows committed since the previous refresh. The post says this can be used to copy append-only data into another ClickHouse table or to replicate an event stream from a MergeTree table into an Iceberg data lake.
Per the same post, block-number and block-offset columns provide the cursor ClickHouse uses to identify rows committed after the previous refresh. For an Iceberg target, the post says ClickHouse stores the incremental cursor in the snapshot summary, and that if ClickHouse restarts, the next refresh resumes from that position instead of replaying the same events. The post credits Smita Kulkarni as the contributor.
CREATE TOKEN
According to the release post, CREATE TOKEN lets a user create a time-limited credential for applications, scripts, CI jobs, and agents without exposing or replacing their main password. The post states that a token never grants more privileges than the user already has and stops working when it expires or if the user is removed. If no VALID UNTIL or VALID FOR is given, the default lifetime is 30 minutes, and ClickHouse displays the token only once. The slides show the syntax CREATE TOKEN VALID FOR INTERVAL 7 DAY GRANTS (SELECT ON default.sales);. The post credits Alexey Milovidov.
LIMIT with boundary conditions
The release post says 26.9 extends LIMIT with boundary conditions that start and stop output based on values in the ordered result stream, “a capability that, to our knowledge, is not currently available in any other database.” That is ClickHouse’s own claim and was not independently verified. AFTER includes the row that matches its condition, UNTIL stops before its matching row, and ALL applies the boundary each time the condition matches. One example in the post, LIMIT 5 AFTER status >= 500, starts at the first server-error response in a log table and returns five requests. The post credits Zakhar Kravchuk and Nihal Miaji.
Performance and other changes
- Min, max and count from statistics: the post says ClickHouse stores minimum and maximum values for numeric-like columns in each data part, and as of 26.9 can use those statistics to answer
min,max, andcountqueries without reading the underlying column data. Theuse_statistics_for_min_max_aggregationsetting disables the optimization. - DISTINCT spilling: setting
max_bytes_before_external_distinctletsDISTINCTspill its intermediate state to disk. The post says ClickHouse automatically enables externalDISTINCTwhenmax_bytes_ratio_before_external_distinctis set to 0.5, meaning spilling starts when it reaches half of the memory available. - JSON and time types: the post says 26.9 adds bracket syntax for accessing paths in a
JSONvalue, and allowsTimevalues as offsets when adding to or subtracting fromDateTimevalues. - PromQL: the post says 26.9 expands PromQL support with more functions, additional Prometheus HTTP API endpoints, and direct
SELECTqueries against TimeSeries tables. PromQL and the TimeSeries table engine are in private preview on ClickHouse Cloud.
What We Don’t Know
- Both cited sources are published by ClickHouse itself; no independent benchmarks or third-party evaluation of the new features were found.
- The sources reviewed do not state how the incremental refresh mode behaves for update- or delete-heavy source tables, since the described use case is append-only data.
- No source reviewed gives performance figures for the min/max/count statistics optimization or the DISTINCT spilling path.