ClickHouse Cloud split still lacks elasticity

The real bottleneck is not whether storage sits in object storage, it is whether compute can disappear when idle and reappear in the right shape for the next job without constant sizing work. ClickHouse Cloud has moved far toward separated storage and stateless compute, but the surrounding unit of deployment is still a service or warehouse that teams size, isolate, and tune for different workloads. That leaves a gap between architectural decoupling and truly hands off elasticity, especially for bursty analytics and mixed ETL plus dashboard traffic.

• ClickHouse Cloud now supports separate storage and compute, auto scaling, scale to zero, and stateless compute. It also added warehouses so teams can split readers, writers, and BI traffic onto different compute groups. That improves isolation, but it also shows elasticity still depends on workload planning at the service layer.
  2 clickhouse 3 clickhouse 4 clickhouse
• The interview lines up with ClickHouse's broader market pattern. Open source ClickHouse wins engineers first because it is fast and cheap for append only event data, then managed cloud has to justify a meaningful premium for easier operations. When workloads are predictable, self hosting often keeps that tradeoff attractive.
  1 sacra 5 sacra 6 sacra
• Firebolt's pitch makes the contrast concrete. Its engines can auto start on query, auto stop after idle time, and be resized without stopping. In practice that means a team can keep separate compute pools off most of the day, then wake them only for scheduled jobs or interactive traffic spikes.
  7 firebolt 8 firebolt

This heads toward a market where managed analytical databases are judged less on having object storage underneath and more on how little human capacity planning they require. ClickHouse is closing that gap quickly, and the next competitive frontier is turning strong low level primitives into a service that feels automatic at production scale.