Trend-Based Projections
Back to Performance Tuning and Capacity Planning · Per-Resource Runway · Lead-Time Awareness · Scenario Modeling · Service Offerings
Extrapolating from actual usage growth, not a generic percentage guess. The guess is the problem. “We grow about twenty per cent a year” sounds like a measurement and is a recollection, and the illustration above shows what that costs: the same twenty-six months, projected two ways, with one saying plan this quarter and the other saying there is nothing to plan for.
This is the compute counterpart to growth forecasting, which does the same for physical capacity — rack space, power, cooling. The arithmetic is similar and the lead times are not, which is the subject of lead-time awareness.
1. Fit the Line to the Data You Have
The method is deliberately plain: take the measured series, fit a line, extend it to the limit, read off the date. Doing that properly beats a sophisticated model on a guessed input every time.
- Use the real series, not a remembered rate. Billing records, monitoring history and backup sizes are all usable sources when nothing was explicitly kept.
- A straight line is usually enough. The value is in having a date at all. Where growth is genuinely compounding — users inviting users — fit the logarithm instead, but check that it is before assuming it.
- State the assumption: the recent past continues. That is false the moment anything changes, which is why scenario modeling exists.
- Project to the usable limit, not the physical one. A disk is in trouble well before it is full, and a database is in trouble well before its connection limit.
2. How Much History You Need
| History available | What it can support |
|---|---|
| Under 3 months | Little. A single busy week dominates the slope |
| 6 months | A usable short-range projection, if nothing seasonal falls inside it |
| 13 months | The first point at which this year can be compared with the same month last year |
| 2 years or more | Seasonality separable from growth, which is when the number becomes trustworthy |
Thirteen months is the figure worth remembering, and the one retention policies usually miss. Twelve is not enough: comparing this July to last July needs a little more than a year in hand.
3. The Mistakes That Produce a Confident Wrong Answer
- Fitting across a step change. A migration, a new customer or a feature launch creates a jump, and a line drawn through it describes neither the period before nor the one after. Fit from the step.
- Mistaking seasonality for growth. Four months measured from January to April will overstate a business whose quiet season is summer.
- Averaging away the peak. Capacity is consumed by the peak, not the mean. Project the busy-period figure.
- Forgetting that data is rarely deleted. Storage growth is close to monotonic, which makes it the easiest resource to forecast and the one most often left until it is urgent.
- Projecting a ratio instead of a quantity. “Sixty per cent utilised” moves when capacity changes as well as when usage does.
4. Check the Forecast Against What Happened
A projection made once is an opinion. A projection compared against the outcome is a method that improves, and the comparison costs nothing because both numbers already exist.
- Record each projection with its date and its assumptions.
- Three months later, put the actual beside it.
- A forecast that is consistently low is worth a correction factor; one that is erratic means the growth is not steady and a different approach is needed.
This is also the only honest way to answer how much confidence the number deserves. See forecast versus actual, where it becomes a standing review.
5. Give a Range, Not a Date
“We reach capacity on 14 March” is more precise than the data supports and invites the objection that it cannot possibly be known. “Between February and May, most likely March” is defensible and leads to the same decision.
Where the range matters is at its near end: plan against the earliest plausible date, because that is the one that can hurt you.
How We Approach It
- Find the longest usable history for each resource, from monitoring, billing or whatever else recorded it incidentally.
- Fit against the peak rather than the average, with step changes handled by fitting from them rather than through them.
- Separate seasonality from growth where more than a year exists.
- Project to the usable limit, as a range, with the assumptions written beside it.
- Record the projection so it can be checked later.
- Set the review interval from the shortest runway found, not from the calendar.
What You Get
- A growth rate per resource measured from your own history, replacing whatever figure is currently being repeated.
- A date range to the usable limit for each, with the near end identified as the planning date.
- Step changes and seasonality handled explicitly rather than averaged into the slope.
- The projections recorded so the next review can score them.
- A review interval derived from the shortest runway rather than from habit.
The test is simple. Ask what your growth rate is, and then ask what it is measured from. If the second question has no answer, the first one is a recollection.