Skip to main content
Skip to main content
Edit this page

Automatic scaling

Scaling is the ability to adjust available resources to meet client demands. Scale and Enterprise (with standard 1:4 profile) tier services can be scaled horizontally by calling an API programmatically, or changing settings on the UI to adjust system resources. These services can also be autoscaled vertically to meet application demands.

Scale plan feature

Automatic vertical scaling is available in the Scale and Enterprise plans. To upgrade, visit the plans page in the cloud console.

Note

Scale and Enterprise tiers support both single and multi-replica services, whereas, the Basic tier supports only single replica services. Single replica services are meant to be fixed in size and don't allow vertical or horizontal scaling. You can upgrade to the Scale or Enterprise tier to scale your services.

How scaling works in ClickHouse Cloud​

Currently, ClickHouse Cloud supports vertical autoscaling and manual horizontal scaling for Scale tier services.

For Enterprise tier services scaling works as follows:

  • Horizontal scaling: Manual horizontal scaling will be available across all standard and custom profiles on the enterprise tier.
  • Vertical scaling:
    • Standard profiles (1:4) will support vertical autoscaling.
    • Custom profiles (highMemory and highCPU) don't support vertical autoscaling or manual vertical scaling. However, these services can be scaled vertically by contacting support.
Note

Scaling in ClickHouse Cloud happens in what we call a "Make Before Break" (MBB) approach. This adds one or more replicas of the new size before removing the old replicas, preventing any loss of capacity during scaling operations. By eliminating the gap between removing existing replicas and adding new ones, MBB creates a more seamless and less disruptive scaling process. It is especially beneficial in scale-up scenarios, where high resource utilization triggers the need for additional capacity, since removing replicas prematurely would only exacerbate the resource constraints. As part of this approach, we wait up to an hour to let any existing queries complete on the older replicas before removing them. This balances the need for existing queries to complete, while at the same time ensuring that older replicas don't linger around for too long.

Learn more​