Storage growth projection:
when you will run out of disk

The compounding formula for data growth

Data often grows by a roughly constant percentage each period, because more users create more data and older data is retained. That is exponential growth, and it is described by the compound formula used for savings, not by simple addition.

The same inputs would give 12 + 12 × 0.04 × 24 = 23.5 TB if you added growth linearly. That is a 7 TB shortfall in a plan, which is a very real gap when you are ordering hardware.

Monthly rate versus annual rate

Rates do not scale by multiplying by twelve. A 4 percent monthly rate compounds to 1.04¹² = 1.601, which is 60.1 percent a year, not 48 percent. Going the other way, a 20 percent annual increase corresponds to a monthly rate of about 1.53 percent.

Always state the period with the percentage. A statement that storage grows 5 percent is meaningless until it says per week, per month or per year.

When will you hit the limit?

The more useful question is often the date a threshold is reached. Rearranging the compound formula gives the number of periods directly.

Do not plan to the full figure. Many teams alert at 70 to 80 percent and order capacity ahead of it, since procurement, migration and rebalancing take time. At 80 percent of 40 TB (32 TB), the same sum gives about 25 months.

Turning logical data into hardware to buy

The projection gives logical data. What you purchase is raw capacity, which has to cover replication and a safety margin. Take the 30.8 TB forecast with three-way replication and an 80 percent fill target.

That is almost four times the headline figure, and it is the number that should reach finance. Erasure coding, compression or a lower replica count change the multiplier, so state the assumption next to the result.

What to count in the starting figure

• Replication: a three-way replicated cluster uses roughly three times the logical data.
• Backups and snapshots: retained copies and versions multiply the footprint.
• Indexes and overhead: databases often store much more than the raw rows.
• Free-space reserve: file systems and databases degrade when nearly full, so usable space is below raw capacity.
• Retention policy: deleting data after a fixed time turns unbounded growth into a plateau.

Be consistent. Project logical data and apply the multiplier at the end, or project raw usage from the start, but do not mix them.

When compound growth is the wrong model

Some workloads add a roughly fixed amount per day, such as logs from a constant number of servers or a camera recording at a set bitrate. That is linear: size = S₀ + daily ingest × days. A 500 GB per day feed adds 15 TB in a 30-day month with no compounding at all.

Others grow in steps, like a launch in a new region or a migration. Fit the model to your own usage history: plot a few months of readings, test whether the curve is straight, bending upward, or flattening, and choose accordingly. Re-run the projection every quarter, because a forecast is only a guess that improves with new measurements.

Use a calculator to produce the baseline quickly, then adjust it with the known events your team expects.

Slowing the curve before buying more

Growth rates are not fixed. Trimming the rate from 4 to 3 percent a month changes the 24-month result from 30.8 TB to 24.4 TB, a saving of about 6.4 TB, and moves the date for reaching 40 TB from month 31 to month 41.

• Set retention limits on logs, backups and temporary files, with automatic expiry.
• Move cold data to cheaper tiers, so fast disks hold only what is used.
• Compress and deduplicate where the data allows it.
• Find the largest consumers each quarter; a few datasets usually account for most of the growth.

Treat the projection as a living number. Compare the forecast with the actual reading each month, and when they drift apart, revise the rate rather than the faith.

A projection table you can check against reality

A table of expected usage at fixed points gives you something to compare with the monitoring graph each month. These figures start at 12 TB and grow 4 percent a month.

The table makes the decision points visible. The 70 percent mark arrives a little after month 20, so a team that needs three months to commission new capacity should start the order at around month 17. Put the review date in a calendar rather than relying on someone noticing the graph.

When actual readings run above the table for two months in a row, fit a new rate to the recent data and rebuild it. Small changes in rate matter a great deal over two years, and catching one early costs far less than an emergency purchase.

Finally, present the forecast as a range, not a single line. Run a cautious case with a lower rate, an expected case, and a high case with a rate a point or two above it, then plan purchases against the expected line while watching the high one. The width of that band shows decision makers how much is uncertain, and it is far easier to justify a buffer when the reasoning is visible on the page.