If your analytics stack leans on cloud object storage, ClickHouse® 26.3 S3 object storage read enhancements are the headline reason to upgrade. This LTS release rethinks how ClickHouse® pulls data from S3 and S3-compatible endpoints, and the result is measurably faster queries against Parquet, Iceberg, Delta Lake, and Hudi tables sitting in a data lake - without any schema changes or application rewrites.
For teams running ClickHouse® directly against S3 buckets instead of loading everything into local MergeTree tables, read performance has historically been the tradeoff you accepted for flexibility and lower storage cost. 26.3 narrows that gap considerably.
What Changed in ClickHouse® 26.3
The core improvement is in the object storage read path itself. According to the ClickHouse® 26.3 release notes, reading from data lakes is now tens of times faster on multi-core machines when queries touch a small number of files - and this applies broadly, not just to one table format:
- Covers Iceberg, Delta Lake, Hudi, and general object storage reads
- Includes plain Parquet or CSV files queried through the
s3()table function - Biggest gains show up on the most common real-world shape: a handful of large files scanned by a query with several CPU cores available
Previously, cores sat idle while ClickHouse® waited on network I/O to S3. 26.3 parallelizes that wait across cores instead of serializing it, which is where most of the speedup comes from.
Alongside the raw throughput gain, ClickHouse® 26.3 introduces a new SLRU cache for Parquet metadata (the file footer). Every time ClickHouse® opens a Parquet file, it needs to read the footer to understand schema and row group layout, and re-fetching that footer on every query adds up fast for dashboards or repeated queries hitting the same files. Key details:
- Enabled by default - no configuration change needed
- Cuts reads by up to 2x on regular queries
- Especially useful for repeated queries over the same Parquet files
- Consistency is guaranteed by tracking file modification via ETag, so stale metadata is never served silently
Smarter Metadata Handling for Data Lake Tables
Iceberg users get a dedicated win too: asynchronous metadata prefetching. Instead of hitting the Iceberg catalog on every SELECT, you can configure a background refresh interval:
CREATE TABLE my_iceberg (...)
ENGINE = IcebergS3(...)
SETTINGS iceberg_metadata_async_prefetch_period_ms = 60000;
SELECT ... FROM my_iceberg
SETTINGS iceberg_metadata_staleness_ms = 30000;ClickHouse® periodically refreshes the metadata cache in the background, and queries simply use the cached version if it's fresh enough - eliminating a catalog round trip from the query's critical path entirely.
Lower-Overhead Ingestion from Object Storage
Read enhancements aren't limited to SELECT queries. S3Queue, ClickHouse®'s mechanism for continuously ingesting new files from an S3 prefix, previously had to re-list the entire prefix history to find new files. In 26.3, ordered-mode S3Queue uses the StartAfter parameter instead:
- Avoids re-listing full prefix history on every check
- Meaningfully reduces
ListObjectsAPI calls - Delivers a direct cost and latency win for queues sitting on prefixes with years of history
There's also a memory-efficiency improvement for semi-structured data. More accurate size calculation when reading a few subcolumns out of a JSON object can lower memory usage by up to 8x for heavy JSON payloads - relevant if your S3-backed lake stores event or log data as JSON blobs rather than flat columns.
What This Means for Your Architecture
None of these changes require rewriting queries or migrating data. If you're already running s3() table functions, IcebergS3 / DeltaLakeS3 engines, or S3Queue pipelines, upgrading to 26.3 LTS should improve read latency and reduce API call volume with settings that are largely enabled by default. That's a meaningful shift for teams weighing whether to keep data in S3 long-term versus importing it into local MergeTree storage - the performance penalty for querying object storage directly just got smaller.
If you're still deciding how object storage fits into your ClickHouse® setup, our deeper walkthrough on ClickHouse® and S3 Integration: Querying Data Lakes querying data lakes with ClickHouse® and S3 covers file formats, partitioning, and when to promote hot data into local tables. And for the full picture of everything else that shipped in this release - async inserts by default, materialized CTEs, and more - see our ClickHouse® 26.3 LTS guide.
Getting Started
Most of these improvements are enabled by default after upgrading to 26.3 LTS, but a few are worth setting explicitly:
- Confirm
use_parquet_metadata_cacheis on for repeated Parquet-heavy workloads - Set
iceberg_metadata_async_prefetch_period_mson high-traffic Iceberg tables to avoid catalog round trips - Switch S3Queue tables to ordered mode if you're on a long-running queue and haven't already
Final Thoughts
Object storage was always going to be the long-term home for cold and warm analytical data - the question was always how much of a performance tax you'd pay for querying it directly instead of local disk. ClickHouse® 26.3 shrinks that tax considerably, and it does so without asking you to touch your queries, your table engines, or your ingestion pipelines. If you're on an earlier version and leaning on S3, Iceberg, Delta Lake, or Hudi in any capacity, this is one of the more practical reasons to plan the upgrade.
If you'd like help evaluating whether your current S3-backed setup is taking full advantage of these changes, or planning the upgrade path to 26.3 LTS, Quantrail™ Data works with teams on exactly this - from architecture reviews to hands-on migrations.
