<!-- mobian-agent-page publisher="dailydev" canonical="https://daily.dev/posts/fixed-cadence-to-seconds-making-clickhouse-cloud-autoscaling-more-reactive-mrdritdf5" -->

---
title: Fixed cadence to seconds: making ClickHouse Cloud...
description: ClickHouse Cloud's autoscaling previously ran on a fixed timer, causing delays when services suddenly needed more resources. The team rebuilt the orchestration...
canonical: https://daily.dev/posts/fixed-cadence-to-seconds-making-clickhouse-cloud-autoscaling-more-reactive-mrdritdf5
twitter:card: summary_large_image
twitter:site: @dailydotdev
og:type: website
og:site_name: daily.dev
og:title: Fixed cadence to seconds: making ClickHouse Cloud autoscaling more reactive | daily.dev
og:description: ClickHouse Cloud's autoscaling previously ran on a fixed timer, causing delays when services suddenly needed more resources. The team rebuilt the orchestration...
og:url: https://daily.dev/posts/fixed-cadence-to-seconds-making-clickhouse-cloud-autoscaling-more-reactive-mrdritdf5
og:image: https://api.daily.dev/og/posts/MrdriTDf5.png
og:image:alt: Fixed cadence to seconds: making ClickHouse Cloud autoscaling more reactive
og:image:width: 1200
og:image:height: 630
og:locale: en
---

> ## Documentation Index
> Fetch the complete documentation index at: https://daily.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Fixed cadence to seconds: making ClickHouse Cloud autoscaling more reactive

**[ClickHouse](https://daily.dev/sources/clickhouse)** · 15 min read · 2 upvotes · 0 comments

## Summary

ClickHouse Cloud's autoscaling previously ran on a fixed timer, causing delays when services suddenly needed more resources. The team rebuilt the orchestration layer using controller-runtime (the Kubernetes operator library) as a general-purpose event-processing engine, adding a reactive fast path alongside the existing periodic sweep. Signal events (like out-of-memory breaches) are written as rows into a small ClickHouse table with a 1-hour TTL. A materialized view filters relevant metrics at insert time, and the reactive source polls this table every few seconds to enqueue services needing immediate attention. The shared work queue handles deduplication, exponential backoff, and bounded concurrency automatically. The result: critical events like OOM now trigger scale-up in seconds rather than waiting for the next scheduled pass, while the periodic sweep remains as a safety net for scale-down and steady-state verification.

## Full article

daily.dev links to this article rather than hosting it. Read it at the original source: <https://clickhouse.com/blog/making-clickhouse-cloud-autoscaling-more-reactive>

## Questions this post answers

### How can I use Kubernetes controller-runtime as a general-purpose job queue outside of Kubernetes?

Controller-runtime's work queue can serve as a general-purpose event-processing engine because its deduplication, exponential backoff, and bounded concurrency are not tied to Kubernetes objects. A source just needs to implement a Start method that pushes reconcile.Request items into a workqueue.TypedRateLimitingInterface; the reconciler then processes them as idempotent units of work, regardless of where the triggers originate.

_See how daily.dev surfaces engineering deep dives like this one for teams evaluating controller-runtime beyond Kubernetes._

### How do you build a low-latency reactive trigger on top of ClickHouse without a separate message queue?

A small ClickHouse table can act as a signal queue: write breach events as rows tagged by service and timestamp, then poll it every few seconds with a tight time-range query like a 5-minute lookback window. Because the table is ordered by scrape_ts with a 1-hour TTL, each poll touches roughly a single granule, keeping query latency in milliseconds even under high ingestion rates.

_Developers designing real-time analytics pipelines can track approaches like this via daily.dev._

### Why use a materialized view instead of querying a large metrics table directly for autoscaling signals?

Querying a large Prometheus metrics table ordered by (service_name, metric_name, scrape_ts) for a fleet-wide time-based poll would scan an entire partition, since the query filters only on scrape_ts, which isn't the leading key. A materialized view filters breach rows incrementally at insert time and writes only matching rows into a small dedicated table, making the read side a cheap, granule-sized scan.

_daily.dev helps engineers comparing materialized view patterns for real-time filtering stay current._

## Similar posts on daily.dev

- [Smarter Auto-Scaling for ClickHouse: The Two-Window Approach](https://daily.dev/posts/smarter-auto-scaling-for-clickhouse-the-two-window-approach-owdxfwfwd) · ClickHouse · 8 upvotes · 0 comments
- [How Trigger.dev is using ClickHouse to scale observability for long-running AI workflows](https://daily.dev/posts/how-trigger-dev-is-using-clickhouse-to-scale-observability-for-long-running-ai-workflows-1urnkfdl2) · ClickHouse · 0 upvotes · 0 comments
- [Running out of runway: migrating Temporal Cloud's billing store to ClickHouse](https://daily.dev/posts/running-out-of-runway-migrating-temporal-cloud-s-billing-store-to-clickhouse-rpxl3uwjt) · Temporal · 0 upvotes · 0 comments

---

Tags: [#kubernetes](https://daily.dev/tags/kubernetes), [#clickhouse](https://daily.dev/tags/clickhouse)

[View this post on daily.dev](https://daily.dev/posts/fixed-cadence-to-seconds-making-clickhouse-cloud-autoscaling-more-reactive-mrdritdf5)

```json
{"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]}
{"@context":"https://schema.org","@type":"TechArticle","headline":"Fixed cadence to seconds: making ClickHouse Cloud autoscaling more reactive","url":"https://daily.dev/posts/fixed-cadence-to-seconds-making-clickhouse-cloud-autoscaling-more-reactive-mrdritdf5","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/fixed-cadence-to-seconds-making-clickhouse-cloud-autoscaling-more-reactive-mrdritdf5"},"datePublished":"2026-08-04T13:19:50.935Z","dateModified":"2026-09-14T07:17:24.653Z","description":"ClickHouse Cloud's autoscaling previously ran on a fixed timer, causing delays when services suddenly needed more resources. The team rebuilt the orchestration...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/534ad2b6e5203bce0f773aa86c749c7f?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/534ad2b6e5203bce0f773aa86c749c7f?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"ClickHouse","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"ClickHouse","logo":"https://media.daily.dev/image/upload/t_logo,f_auto/v1/logos/clickhouse","url":"https://daily.dev/sources/clickhouse"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/fixed-cadence-to-seconds-making-clickhouse-cloud-autoscaling-more-reactive-mrdritdf5","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":2},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"kubernetes,clickhouse","timeRequired":"PT15M"}
{"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"ClickHouse","item":"https://daily.dev/sources/clickhouse"},{"@type":"ListItem","position":3,"name":"Fixed cadence to seconds: making ClickHouse Cloud autoscaling more reactive"}]}
{"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/fixed-cadence-to-seconds-making-clickhouse-cloud-autoscaling-more-reactive-mrdritdf5#faq","mainEntity":[{"@type":"Question","name":"How can I use Kubernetes controller-runtime as a general-purpose job queue outside of Kubernetes?","acceptedAnswer":{"@type":"Answer","text":"Controller-runtime's work queue can serve as a general-purpose event-processing engine because its deduplication, exponential backoff, and bounded concurrency are not tied to Kubernetes objects. A source just needs to implement a Start method that pushes reconcile.Request items into a workqueue.TypedRateLimitingInterface; the reconciler then processes them as idempotent units of work, regardless of where the triggers originate. See how daily.dev surfaces engineering deep dives like this one for teams evaluating controller-runtime beyond Kubernetes."}},{"@type":"Question","name":"How do you build a low-latency reactive trigger on top of ClickHouse without a separate message queue?","acceptedAnswer":{"@type":"Answer","text":"A small ClickHouse table can act as a signal queue: write breach events as rows tagged by service and timestamp, then poll it every few seconds with a tight time-range query like a 5-minute lookback window. Because the table is ordered by scrape_ts with a 1-hour TTL, each poll touches roughly a single granule, keeping query latency in milliseconds even under high ingestion rates. Developers designing real-time analytics pipelines can track approaches like this via daily.dev."}},{"@type":"Question","name":"Why use a materialized view instead of querying a large metrics table directly for autoscaling signals?","acceptedAnswer":{"@type":"Answer","text":"Querying a large Prometheus metrics table ordered by (service_name, metric_name, scrape_ts) for a fleet-wide time-based poll would scan an entire partition, since the query filters only on scrape_ts, which isn't the leading key. A materialized view filters breach rows incrementally at insert time and writes only matching rows into a small dedicated table, making the read side a cheap, granule-sized scan. daily.dev helps engineers comparing materialized view patterns for real-time filtering stay current."}}]}
```

