Smarter Auto-Scaling for ClickHouse: The Two-Window Approach

Ashwath Singh, Manas AlekarMar 24, 2026

Source: Clickhouse
Published: Mar 24, 2026
Added to Yomu: Aug 28, 2026

Summary

ClickHouse Cloud required a vertical auto-scaling mechanism that preserves rapid scale-ups while avoiding prolonged over-provisioning after traffic drops. Operating on a single 30-hour lookback window forced scale-downs to take up to 30 hours, whereas an earlier fixed-factor CPU algorithm caused severe oscillations. The engineering team deployed a dual-window recommender pairing a 3-hour window for responsive scale-downs with a 30-hour window for single-step scale-ups. Alongside a trend-based hunting check to resolve conflicting window recommendations, the team introduced target-tracking CPU scaling using geometric mean watermarks and 10-minute median smoothing. This dual-window architecture reduced scale-down latency to 3 hours, prevented scaling oscillations, and significantly reduced infrastructure costs for variable database workloads.

Context

A single 30-hour lookback window in ClickHouse Cloud caused clusters to remain over-provisioned for up to 30 hours after traffic dropped. In addition, the existing CPU recommendation algorithm used fixed doubling or halving factors that triggered severe scaling oscillations with shorter lookback windows.

Approach / What changed

ClickHouse implemented a dual-window recommender combining a 3-hour window and a 30-hour window, using a hunting check on the previous small window trend to resolve disagreements. They also introduced target-tracking CPU scaling with 10-minute median smoothing, selecting the higher recommendation between CPU and memory analyses.

Takeaways

Setting the target utilization to the geometric mean of the high and low watermarks guarantees reversible scaling and prevents allocation drift.
A 3-hour lookback window enables faster scale-downs while the 30-hour window ensures single-step scale-ups to longer-term peak usage.
Comparing the current small window against the previous small window recommendation prevents scaling oscillations when the two lookback windows disagree.

Architecture Observability Performance Scalability

Read original post

Smarter Auto-Scaling for ClickHouse: The Two-Window Approach

Ashwath Singh, Manas AlekarMar 24, 2026

Source: Clickhouse
Published: Mar 24, 2026
Added to Yomu: Aug 28, 2026

Summary

Context

Approach / What changed

Takeaways

Setting the target utilization to the geometric mean of the high and low watermarks guarantees reversible scaling and prevents allocation drift.
A 3-hour lookback window enables faster scale-downs while the 30-hour window ensures single-step scale-ups to longer-term peak usage.
Comparing the current small window against the previous small window recommendation prevents scaling oscillations when the two lookback windows disagree.

Architecture Observability Performance Scalability

Read original post

Related reading

Clickhouse · Apr 21, 2026
Index sharding in ClickHouse Cloud: Petabyte-scale data needs petabyte-scale indexing
In large-scale ClickHouse Cloud deployments, replicas traditionally load entire primary and secondary indexes from object storage into working memory, creating massive redundant memory overhead as fleets expand. Index sharding resolves this bottleneck by distributing the index analysis phase across available replicas using consistent hashing over data parts. Instead of every node loading full index structures, each replica loads and analyzes only its assigned fraction of primary keys, bloom filters, text indexes, or vector indexes. The query initiator merges the resulting granule match ranges, allowing parallel replicas to stream data without any single machine retaining the whole index. This approach freed working memory for query execution and accelerated index analysis by up to 7.7x in benchmark tests on a 50 billion row table.
James Cunningham
Clickhouse · May 27, 2026
Introducing multi-stage distributed query execution in ClickHouse Cloud
ClickHouse Cloud introduced multi-stage distributed query execution to improve scaling for large joins and high-cardinality aggregations across multi-node clusters. Prior execution models relied on physical sharding or parallel replicas, which lacked the ability to freely repartition intermediate data between query stages. By splitting query plans into stages connected by exchange operators, worker nodes can shuffle, broadcast, scatter, or gather intermediate data during execution. In TPC-H benchmarks at scale factor 100 on eight nodes, total query time dropped from 117.6 seconds to 54.7 seconds, with scan-dominated queries showing near-linear 7.4x speedups. While currently in private preview with a rule-based planner, future work includes developing a cost-based optimizer to select optimal aggregation and join strategies automatically.
Alexander Gololobov
Clickhouse · Apr 23, 2026
Do you still need Elasticsearch for log analytics? ClickHouse says no.
ClickHouse introduced a redesigned full-text search powered by inverted indexes that feeds matching documents directly into its vectorized analytical engine for observability and log analytics workloads. To evaluate this capability, the open-source versions of ClickHouse and Elasticsearch were benchmarked on single-node AWS EC2 instances across synthetic OpenTelemetry log datasets scaling up to 50 billion rows. The benchmark evaluated nine representative query patterns combining text search with filtering, grouping, counting, and time-series aggregations under both cold and hot cache conditions. ClickHouse achieved a roughly fivefold smaller storage footprint on disk while running cold queries four to six times faster and hot queries approximately 1.7 to 2.6 times faster than Elasticsearch. Furthermore, ClickHouse ingested the 50-billion-row dataset in under four hours out of the box, whereas the tuned Elasticsearch setup required approximately five days.
Tom Schreiber, Lionel Palacin
Netflix · Aug 21, 2026
A Tale of Two Flink Autoscalers
Netflix operates over 30,000 Apache Flink jobs across multiple AWS regions, ranging from managed pipelines to complex stateful DAGs. Its initial in-house autoscaler used external telemetry from Mantis and Atlas to scale TaskManagers as a single unit, cutting resource usage by 25–45% but failing on multi-operator stateful topologies. To address these limitations, Netflix adopted the Apache Flink Autoscaler library, which calculates True Processing Rate and per-vertex parallelism using internal metrics. The architecture uses Temporal workflows orchestrated within a Spring Boot application to evaluate jobs individually and prevent cross-job blast radiuses. Implementing the open-source autoscaler reduced annualized compute expenditures by 58% for client telemetry and logging, saving approximately $1.1 million.
Netflix Technology Blog