ClickHouse version 25.6 contains 27 new features 🌺 26 performance optimizations 🍦 98 bug fixes 🐞
This release brings ## New Contributors A special welcome to all the new contributors in 25.7! The growth of ClickHouse's community is humbling, and we are always grateful for the contributions that have made ClickHouse so popular. Below are the names of the new contributors: *Alon Tal, Andrey Volkov, Damian Maslanka, Diskein, Dominic Tran, Fgrtue, H0uston, HumanUser, Ilya fanyShu, Joshie, Mishmish Dev, Mithun P, Oleg Doronin, Paul Lamb, Rafael Roquetto, Ronald Wind, Shiv, Shivji Kumar Jha, Surya Kant Ranjan, Ville Ojamo, Vlad Buyval, Xander Garbett, Yanghong Zhong, ddavid, e-mhui, f2quantum, jemmix, kirillgarbar, lan, wh201906, xander, yahoNanJing, yangjiang, yangzhong, 思维* Hint: if you’re curious how we generate this list… [here](https://gist.github.com/gingerwizard/5a9a87a39ba93b422d8640d811e269e9). You can also [view the slides from the presentation](https://presentations.clickhouse.com/2025-release-25.7/). ## Lightweight updates ### Contributed by Anton Popov ClickHouse now supports **standard SQL UPDATE statements at scale**, powered by a new lightweight **patch-part** mechanism. Unlike classic mutations, which rewrite full columns, these updates write only tiny “patch parts” that slide in instantly with minimal impact on query performance. ### How it works Patch parts extend the same principles behind [purpose-built engines](https://clickhouse.com/blog/updates-in-clickhouse-1-purpose-built-engines) like ReplacingMergeTree, but in a fully general way, exposed through [standard SQL](https://www.w3schools.com/sql/sql_update.asp):
UPDATE orders
SET discount = 0.2
WHERE quantity >= 40;
* Inserts are [fast](https://clickhouse.com/blog/updates-in-clickhouse-1-purpose-built-engines#inserts-are-so-fast-we-turned-updates-into-inserts).
* Merges are [continuous](https://clickhouse.com/blog/updates-in-clickhouse-1-purpose-built-engines#merges-are-fast-thanks-to-sorted-parts).
* Parts are [immutable and sorted](https://clickhouse.com/blog/updates-in-clickhouse-1-purpose-built-engines#inserts-create-sorted-and-immutable-parts).
So instead of locating and modifying rows, ClickHouse simply inserts a compact patch part named for what it does: **it patches data parts during merges, applying only the changed data**:
Merges were already running in the background, so we made them do more, with near-zero overhead. They now apply patch parts, updating the base data efficiently as parts are merged.
Updates show up right away, not-yet-merged patch parts are matched and **applied independently for each data range** in each [data stream](https://clickhouse.com/docs/optimize/query-parallelism#distributing-work-across-processing-lanes) in a surgical, targeted way, ensuring that updates are applied correctly without disrupting parallelism:
This makes declarative updates up to **[1,000× faster](https://clickhouse.com/blog/updates-in-clickhouse-3-benchmarks#time-until-bulk-updates-are-visible-to-queries)** than before in our benchmarks, with **minimal impact on queries** before merges.
Whether you’re updating one row or a million, it’s now fast, efficient, and fully declarative.
### DELETE are ~~lightweight~~ featherweight
For DELETES with [standard SQL syntax](https://www.w3schools.com/sql/sql_delete.asp) like:
DELETE FROM orders WHERE order_id = 1001 AND item_id = 'mouse';
ClickHouse simply creates a patch part that sets `_row_exists = 0` for the deleted rows. The row is then dropped during the next background merge:
### Under the hood of fast UPDATEs
Want to go deeper? Check out our 3-part blog series on fast UPDATEs in ClickHouse:
* [Part 1: Purpose-built engines](https://clickhouse.com/blog/updates-in-clickhouse-1-purpose-built-engines)
./clickhouse client -mn
--host sql-clickhouse.clickhouse.com
--secure
--user demo --password ''
?? what was the most popular github repository in July 2025?;
• Starting AI SQL generation with schema discovery...
─────────────────────────────────────────────────
🧠 thinking..[INFO] Text generation successful - model: gpt-4o, response_id: chatcmpl-BxBDkKy9sNi1Bw8E26UC8RXNBMrPT
🔧 Calling: list_databases [call_IXv...]
✓ list_databases completed
└─ Found 37 databases: - amazon - bluesky - country - covid - default - dns - en...
🔧 Calling: list_databases [call_IXv...]
🧠 thinking...✓ list_databases completed
└─ Found 37 databases: - amazon - bluesky - country - covid - default - dns - en...
🧠 thinking..[INFO] Text generation successful - model: gpt-4o, response_id: chatcmpl-BxBDmOwzsHgBNHtOiT8tEIhjJoMXV
🔧 Calling: list_tables_in_database [call_pRq...]
└─ Args: {"database":"github"}
🧠 thinking...✓ list_tables_in_database completed
└─ Found 19 tables in database 'github': - actors_per_repo - actors_per_repo_mv ...
🔧 Calling: list_tables_in_database [call_pRq...]
└─ Args: {"database":"github"}
✓ list_tables_in_database completed
└─ Found 19 tables in database 'github': - actors_per_repo - actors_per_repo_mv ...
🧠 thinking...[INFO] Text generation successful - model: gpt-4o, response_id: chatcmpl-BxBDo0qbEkfvzTl6vgrA49fgjVVfo
🔧 Calling: get_schema_for_table [call_NKK...]
└─ Args: {"database":"github","table":"repo_events_per_day"}
🧠 thinking✓ get_schema_for_table completed
└─ Schema for github.repo_events_per_day: CREATE TABLE github.repo_events_per_da...
🔧 Calling: get_schema_for_table [call_NKK...]
└─ Args: {"database":"github","table":"repo_events_per_day"}
✓ get_schema_for_table completed
└─ Schema for github.repo_events_per_day: CREATE TABLE github.repo_events_per_da...
🧠 thinking.[INFO] Text generation successful - model: gpt-4o, response_id: chatcmpl-BxBDpMp0HpRmFZK2VBZG5y6sWMCsF
─────────────────────────────────────────────────
• ✨ SQL query generated successfully!
SELECT
repo_name,
sum(count) AS total_events
FROM github.repo_events_per_day
WHERE (created_at >= '2025-07-01') AND (created_at <= '2025-07-31')
GROUP BY repo_name
ORDER BY total_events DESC
LIMIT 1;
SELECT
town,
avg(price) AS avg_price
FROM uk_price_paid
GROUP BY town;
Suppose we want the average price in London using two CPU cores:
**① Parallel processing and ② partial aggregation states**
Lane 1 sees two London rows → sum = 500,000, count = 2
Lane 2 sees one London row → sum = 400,000, count = 1
**③ Merge into the ④ final state**
Final avg = (500,000 + 400,000) / (2 + 1) = 300,000
> You **must** merge sums and counts, **not intermediate averages**, to avoid errors like:
SELECT
town,
count() AS count
FROM uk_price_paid
GROUP BY town;
…ClickHouse skips the memory arena entirely.
Since count() is an [additive function](https://en.wikipedia.org/wiki/Additive_function), it doesn’t require a complex aggregation state to correctly merge partial results across lanes. Count() only needs to store a single 64-bit integer (the count itself), which is no larger than a pointer on 64-bit systems, ClickHouse can:
* Store the count **directly** in the hash table cell
* Skip allocating space in the memory arena
* Skip pointer indirection
This avoids memory allocation and pointer chasing altogether, reducing CPU and memory overhead.
In our tests, count() aggregations are now **20–30% faster** than before, with lower memory usage and fewer CPU cycles.
### Why this matters
**Count aggregations are everywhere**: from dashboards ranking the most active users or [most downloaded packages](https://clickhouse.com/blog/clickhouse_vs_elasticsearch_mechanics_of_count_aggregations#count-aggregations-in-clickhouse-and-elasticsearch), to alerting systems tracking unusual event frequencies. Whether it’s analytics, observability, or search, nearly every system relies on fast, efficient count queries. That’s why even small improvements here can have an outsized impact.
### Real-world results
We’ll demonstrate this optimization using a typical analytical query over web analytics data that returns the 10 most active users by using a count() aggregation:
SELECT UserID, count()
FROM hits
GROUP BY UserID
ORDER BY count() DESC
LIMIT 10;
*(You can run the query yourself by [creating](https://github.com/ClickHouse/ClickBench/blob/83d5a48f7a29703064e27a44f1cb918d9f53ff43/clickhouse/create.sql) the table and [loading](https://github.com/ClickHouse/ClickBench/blob/83d5a48f7a29703064e27a44f1cb918d9f53ff43/clickhouse/benchmark.sh#L36) the data)*
We used an **AWS m6i.8xlarge** EC2 instance (32 cores, 128 GB RAM) with a **gp3 EBS volume** (16k IOPS, 1000 MiB/s max throughput) to run the query.
We ran the query 3 times on **ClickHouse 25.6**, and show the runtime statistics returned by clickhouse-client:
10 rows in set. Elapsed: 0.447 sec. Processed 100.00 million rows, 799.98 MB (223.49 million rows/s., 1.79 GB/s.)
Peak memory usage: 2.50 GiB.
10 rows in set. Elapsed: 0.391 sec. Processed 100.00 million rows, 799.98 MB (255.79 million rows/s., 2.05 GB/s.)
Peak memory usage: 2.52 GiB.
10 rows in set. Elapsed: 0.383 sec. Processed 100.00 million rows, 799.98 MB (261.21 million rows/s., 2.09 GB/s.)
Peak memory usage: 2.51 GiB.
10 rows in set. Elapsed: 0.305 sec. Processed 100.00 million rows, 799.98 MB (327.54 million rows/s., 2.62 GB/s.)
Peak memory usage: 2.00 GiB.
10 rows in set. Elapsed: 0.265 sec. Processed 100.00 million rows, 799.98 MB (377.43 million rows/s., 3.02 GB/s.)
Peak memory usage: 1.96 GiB.
10 rows in set. Elapsed: 0.237 sec. Processed 100.00 million rows, 799.98 MB (422.34 million rows/s., 3.38 GB/s.)
Peak memory usage: 1.96 GiB.
SELECT (10, 10)::Point as point,
[(0, 0), (10, 0), (10, 10), (0, 10)]::LineString AS lineString,
[
[(0, 0), (10, 0), (10, 10), (0, 10)],
[(1, 1), (2, 2)]
]::MultiLineString AS multiLineString,
[[(20, 20), (50, 20), (20, 50)], [(30, 30), (50, 50), (50, 30)]]::Polygon AS polygon,
[ [[(0, 0), (10, 0), (10, 10), (0, 10)]],
[[(20, 20), (50, 20), (50, 50), (20, 50)],[(30, 30), (50, 50), (50, 30)]]
]::MultiPolygon AS multiPolygon,
[(0, 0), (10, 0), (10, 10), (0, 10)]::Ring AS ring
INTO OUTFILE 'geo.parquet' TRUNCATE;
DESCRIBE file('geo.parquet');
select polygonsIntersectSpherical(
[[[(-0.140, 51.500), (-0.140, 51.510), (-0.120, 51.510), (-0.120, 51.500), (-0.140, 51.500)]]],
[[[(-0.135, 51.505), (-0.135, 51.515), (-0.115, 51.515), (-0.115, 51.505), (-0.135, 51.505)]]]
);
select polygonsIntersectCartesian(
[[[(0.0, 0.0), (0.0, 64.0), (45.0, 64.0), (45.0, 0.0), (0.0, 0.0)]]],
[[[(55.0, 0.0), (55.0, 64.0), (100.0, 64.0), (100.0, 0.0), (55.0, 0.0)]]]
);
SET param_username = 'test123';
CREATE USER {username:Identifier};
GRANT S3 ON *.* TO user
# config.d/read_write_grants.yaml
access_control_improvements:
enable_read_write_grants: true
GRANT READ, WRITE ON S3 TO user;