Auto Scaling
Auto Scaling adjusts a cluster's compute capacity as workload demand changes. The cluster's cache capacity scales in proportion to its compute tier. Use Auto Scaling for dynamic or difficult-to-predict workloads when you want VeloDB Cloud to manage capacity within limits that you set.
Warning:
- Queries can be delayed or interrupted while the cluster scales.
- When scaling in compute, cache space shrinks proportionally, and data outside the new cache capacity is evicted. Query latency may increase while the cache warms up again.
You can configure Auto Scaling only when all of the following conditions are met:
| Dimension | Requirement |
|---|---|
| Cluster type | Compute cluster |
| Cluster status | Running |
| Configuration | AutoScaling enabled |
Note:
- SaaS free-trial clusters do not support Auto Scaling. Suspended or stopped clusters are excluded from Auto Scaling evaluations.
- Enabling AutoScaling disables Manual Scaling and Time-based Scaling.
Choose CPU limits
| Parameter | What it controls | Choose a value that |
|---|---|---|
| Min CPU Cores | The lowest compute capacity that Auto Scaling can select. | Supports normal traffic without waiting for a scale-out operation, typically 4-16 cores. |
| Max CPU Cores | The highest compute capacity that Auto Scaling can select. | Covers peak traffic while staying within the maximum cost you allow. |
VeloDB Cloud adjusts compute only within the limits you set. The associated cache capacity changes with the selected compute tier. If the workload needs less capacity than Min CPU Cores or more than Max CPU Cores, the cluster remains at the applicable limit.
Configure Auto Scaling
- Log in to the VeloDB Cloud console.
- In the upper-left corner, select the warehouse that contains the cluster.
- In the left navigation pane, under Compute, click Clusters.
- Click the target cluster card to open its details page.
- In On-Demand Resources, click Scale Out/In to open Elastic Scaling.
- Enable AutoScaling.
- Set Min CPU Cores and Max CPU Cores.
- Review the displayed cost, then click Confirm.
Change the scaling strategy
To use a different strategy, disable AutoScaling, then configure manual scaling for an immediate change or time-based scaling for predictable schedules.
How Auto Scaling works
VeloDB Cloud evaluates CPU and memory usage at regular intervals, calculates a target cluster size, maps it to a supported compute tier, and scales when utilization crosses a threshold. Cache capacity changes proportionally when the compute tier changes.
Dual-window analysis
VeloDB Cloud evaluates two time windows to balance fast response with stability:
- Short window (3 hours): Captures sudden traffic changes and lets the cluster scale in soon after traffic drops.
- Long window (30 hours): Captures broader daily peaks so the cluster can scale out to a suitable tier without stepping through many smaller tiers.
Each window recommends scaling out, scaling in, or keeping the current size. VeloDB Cloud combines the recommendations into one scaling decision.
Utilization watermarks
Usage above the high watermark triggers scale-out. Usage below the low watermark triggers scale-in. Usage between the watermarks keeps the cluster at its current size.
The following table shows the default watermarks and target utilization for each resource dimension:
| Resource dimension | Low watermark | High watermark | Target utilization |
|---|---|---|---|
| CPU | 37.5% | 75% | Approximately 53% |
| Memory | 40% | 80% | Approximately 57% |
CPU and memory are evaluated independently. VeloDB Cloud selects the larger target size, so a memory-heavy workload does not scale in only because CPU usage is low, and a CPU-heavy workload can scale out even when memory usage is stable.
Supported compute tiers
Clusters scale across predefined CPU tiers instead of arbitrary core counts. Supported tiers are:
4, 8, 16, 32, 48, 64, 80, 96, 128, 160, 192, ...
Above 80 cores, tiers increase in increments of 32 cores. VeloDB Cloud rounds a calculated target to the closest valid tier. If a recommendation is exactly between two tiers, it selects the larger tier. Min CPU Cores and Max CPU Cores are also aligned to these tiers.
For example, a 16-core cluster reaches a CPU peak of 14 cores during the short window. Its utilization is 87.5%, which is above the 75% high watermark. The recommended capacity is about 27 cores, so VeloDB Cloud selects the nearest supported tier, 32 cores.
If the same 16-core cluster has a sustained CPU peak of 5 cores during the short window, its utilization is about 31%, which is below the 37.5% low watermark. The recommended capacity is about 10 cores, so VeloDB Cloud selects the nearest supported tier, 8 cores.
Stability safeguards
To prevent frequent back-and-forth changes caused by unstable traffic, Auto Scaling applies the following safeguards:
- Cooldown period: After a successful scaling event, VeloDB Cloud waits 15 minutes before making another change. Newly created or restarted clusters also have a 15-minute warm-up window before they are eligible for Auto Scaling.
- Window conflict resolution: When the short and long windows recommend different directions, VeloDB Cloud prioritizes the long window when the short-window trend is rising. When the short-window trend is flat or falling, it prioritizes the short window.
Monitor and tune Auto Scaling
Auto Scaling actions are recorded in Activity Logs with the timestamp, scaling direction, and cluster size before and after the event. Review this history after changing CPU limits to confirm that scaling frequency and capacity match your expectations.
If the cluster repeatedly reaches Max CPU Cores, increase the limit or use manual scaling before a known short-term peak. If capacity stays at Min CPU Cores during recurring quiet periods, consider reducing the minimum.
Best practices
- Align Min CPU Cores with baseline traffic. A value that is too low can require several scaling events during a sudden spike. A value that is too high reduces savings during quiet periods.
- Provide headroom in Max CPU Cores. Set it to about 1.5-2 times expected peak demand when the additional cost is acceptable.
- Before an important launch, campaign, or migration, increase Min CPU Cores in advance and restore it after the event.
- Review Activity Logs regularly. Use scaling history to fine-tune your minimum and maximum CPU limits.
- A cluster can be provisioned with up to 1,024 vCPUs by default. Contact VeloDB Cloud support to request a higher quota.
FAQ
Q: I enabled Auto Scaling, but my cluster size remains unchanged. Why?
This is typically caused by one of the following factors:
- Cooldown active: The cluster was scaled, created, or restarted less than 15 minutes ago.
- Not enough metrics: The short window does not have enough metrics, which is common for a new cluster.
- Stable utilization: Current metrics are within the optimal target bounds (CPU: 37.5%-75%, Memory: 40%-80%).
- Already at the target tier: The calculated target matches the current cluster size.
- Not eligible: The cluster does not meet the basic requirements, for example, it is not in Running status.
Q: Can I disable the 15-minute cooldown to accelerate scale-out times?
No. The cooldown is a system guardrail that prevents repeated scaling loops and resource instability.
If you expect a large, scheduled traffic spike, such as a product launch or flash sale, increase Min CPU Cores in advance and lower it after the event.
Q: Will a scale-in event shrink my cluster to zero and terminate workloads?
No. The cluster does not scale below the configured Min CPU Cores. VeloDB Cloud also enforces a minimum of 4 cores to keep the cluster available.
Q: Is there a risk of runaway scaling causing cost overruns?
No. The query engine respects the Max CPU Cores limit. VeloDB Cloud also enforces a platform limit of 2048 cores per cluster.
See also
- Review scaling strategies to choose the right approach for the workload.
- Manual Scaling for an immediate, one-time capacity change.
- Time-Based Scaling when workload peaks follow a fixed schedule.