Storage Growth Forecaster
A storage growth forecaster. Enter your current data size and either a daily ingest rate or a monthly growth percentage, set a replication factor, and see your projected size at 3, 6, 12 and 24 months — plus when you would cross a capacity threshold. Handy for capacity planning databases, logs, object stores and backups.
| Horizon | Logical | Raw (×3) |
|---|---|---|
| 3 months | 2.3 TB | 7.0 TB |
| 6 months | 4.2 TB | 12.5 TB |
| 12 months | 7.8 TB | 23.4 TB |
| 24 months | 15.1 TB | 45.3 TB |
Running out of disk is a predictable failure, which means it is an avoidable one. The forecast starts from where you are and applies how you grow. If ingest is steady — logs, events, metrics — growth is linear: a fixed number of gigabytes a day. If it scales with your users or dataset, growth is compound: a percentage a month, where each month adds more than the last. Picking the right model matters, because linear quietly under-predicts a growing product while compound over-predicts a mature one — so forecasting both brackets the truth.
Then multiply by reality. The disk you provision is the logical data times your replication factor: keep three copies for durability and 10 TB becomes 30 TB of raw storage. Retention pulls the other way — for append-only data with a fixed window, size plateaus once old data ages out as fast as new data arrives, settling near ingest × retention × replication. Keep everything forever and there is no plateau.
The output that matters is a date: when you cross your capacity threshold. And that threshold is not 100% — storage systems degrade well before full, needing headroom for compaction, temp files and bursts, so teams act at 70–80%. The forecaster reports when you hit the line you set, which is your deadline to have new capacity provisioned, comfortably before the day you would actually run out.
How it works
- Linear (per-day) or compound (per-month %) growth models.
- Replication factor multiplies logical size to raw disk.
- Projects size at 3, 6, 12 and 24 months.
- Tells you when you cross a capacity threshold.
Frequently asked questions
Linear or compound growth — which should I use?
Use linear (a fixed amount per day) when ingest is roughly steady — logs, sensor data, append-only events at a stable rate. Use compound (a percentage per month) when growth scales with an expanding user base or dataset, so each month adds more than the last. Many real systems are somewhere between; forecast both to bracket your planning. Linear tends to under-predict a growing product; compound can over-predict a mature one.
Why multiply by the replication factor?
Because the disk you must provision is the logical data times how many copies you keep. A 3× replication factor means every byte is stored three times across nodes for durability and availability, so 10 TB of logical data needs 30 TB of raw disk. Erasure coding changes the multiplier (often ~1.4× instead of 3×) but the principle is the same: plan for the physical footprint, not the logical size.
Where does retention fit in?
For append-only data with a retention window, growth is not unbounded — once you reach the retention limit, old data ages out at roughly the rate new data comes in, and the size plateaus. If you keep everything forever, it grows without limit. This forecaster projects gross growth; if you have a retention policy, the steady-state size is roughly ingest rate × retention period × replication, which is often the number that actually matters.
What should I plan capacity against?
Not 100% of your disk. Databases and file systems degrade well before full — you want headroom for compaction, temporary files, spikes and the lead time to add capacity. A common rule is to act at 70–80% utilization. Set your threshold accordingly, and the forecaster tells you when you cross it, which is the date you need new capacity provisioned by, not the date you actually run out.