The Data Warehouse Capacity Needs Estimator projects how much warehouse compute capacity may be required as workload grows, then adds a configurable headroom buffer for peaks, concurrency, maintenance, or forecasting uncertainty. It is meant for teams that can express current demand and current provisioned capacity in the same abstract capacity unit—credits per hour, compute units, slot equivalents, or another internal planning measure.
The estimator first scales current demand by the expected workload growth rate. It then increases that projected demand by the desired headroom percentage to calculate a target capacity. Comparing that target with your current provisioned capacity shows the additional capacity that may be needed. This is a planning model, not a performance benchmark: query mix, caching, clustering, concurrency behavior, auto-scaling, and vendor architecture can all change the relationship between workload growth and compute demand.
Demand and capacity assumptions
capacity units
%
%
capacity units
Result
—
Target warehouse capacity
Projected demand—
Headroom amount—
Additional capacity needed—
Capacity change—
1. Define the capacity unit Use one consistent unit for current demand and provisioned capacity.
2. Enter current peak demand Provide the observed or estimated demand level during the period you need to support.
3. Apply expected growth Enter the percentage increase in workload you want to plan for.
4. Set headroom Add a buffer above projected demand for peaks and uncertainty.
5. Enter current capacity Provide the amount currently provisioned in the same capacity unit.
6. Review the target Use the target and additional-capacity figures as a sizing scenario, then validate against workload tests or platform-specific guidance.
All capacity values use the same user-defined capacity unit. Growth Rate and Headroom are entered as percentages and converted to decimals. The model assumes capacity requirements scale proportionally with workload; real systems may scale nonlinearly because of query optimization, concurrency, caching, or autoscaling behavior.
What the result means
The main result is the modeled capacity needed to cover projected demand plus the selected headroom buffer.
Validate the estimate with real query performance and concurrency data before making platform-specific sizing decisions.
Given: current peak demand of 80 units, 25% expected growth, 20% headroom, and 120 units of current capacity.
Result: The current 120-unit provision exactly matches the modeled target under these assumptions. Any change in growth or headroom will change the recommended capacity.
What should “current peak demand” represent?
Use the demand metric that best corresponds to your capacity unit, ideally from a representative busy period. Average usage can understate capacity needs when concurrency is spiky.
Why add headroom after growth?
The model first estimates future demand and then reserves a buffer above that future level. This keeps the headroom tied to the workload you are planning to support.
Can the calculator recommend less capacity than I have now?
The target itself can be below current capacity, but Additional capacity needed is floored at zero. Compare target capacity with your current provision to identify possible over-provisioning.
Does this model auto-scaling?
No. It estimates a target capacity level. Auto-scaling policies may let you provision differently depending on minimums, maximums, startup time, and workload volatility.
How is this different from utilization rate?
Capacity needs is forward-looking and adds growth plus headroom. Utilization rate measures how much of existing capacity is currently being used.