Vibe Engines is free, interactive AI engineering & system design — runs in your browser. Pick a learning path
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 makes it an avoidable one. This forecaster starts from today’s size, applies a growth model, multiplies by the copies you keep and tells you when the raw footprint crosses the capacity line you set.
What it computes
linear: logical(m) = current + GB per day × 30.44 × m
compound: logical(m) = current × (1 + monthly % / 100)^m
raw(m) = logical(m) × replication
cross = first whole month m, from 0 to 120, where raw(m) ≥ threshold TB × 1,000- m is months from now; 30.44 is the average month length in days.
- Logical size is the data itself; raw is what lands on disk across all copies.
- The table shows both at 3, 6, 12 and 24 months. Sizes use decimal units: 1,000 GB is shown as 1.0 TB and 1,000 TB as 1.0 PB.
- The crossing is reported as years and months, “already over” if today’s raw size exceeds the threshold, or “not within 10 years”.
A worked example
The defaults are linear growth from 500 GB at 20 GB a day, with 3 replicas and a 10 TB threshold. Each month adds 20 × 30.44 = 608.8 GB of logical data.
| Horizon | Logical | Raw (×3) |
|---|---|---|
| 3 months | 500 + 3 × 608.8 = 2,326 GB, shown 2.3 TB | 7.0 TB |
| 6 months | 4,153 GB, shown 4.2 TB | 12.5 TB |
| 12 months | 7,806 GB, shown 7.8 TB | 23.4 TB |
| 24 months | 15,111 GB, shown 15.1 TB | 45.3 TB |
The crossing: raw reaches 10,000 GB when logical reaches 10,000 / 3 = 3,333 GB, which is (3,333 − 500) / 608.8 = 4.65 months in. The first whole month past that is 5, so the tool reports in ~5mo (month 5). At that point the logical data is only about 3.3 TB; replication is what fills the 10 TB.
Switch to compound at the default 8% a month and the same 500 GB grows far more slowly at first: 630 GB at 3 months, 1.3 TB at 12 and 3.2 TB at 24, crossing 10 TB raw at month 25, about two years out. Compound starts small and accelerates, so it overtakes any linear rate eventually.
Assumptions and limits
- Smooth growth. Real ingest has seasonality, launches and backfills; the model draws a clean curve.
- No deletion or compression. Retention, compaction, deduplication and compression all reduce the real footprint and are not applied.
- Whole replicas. Replication multiplies everything by the same factor; erasure-coded storage needs a smaller multiplier you can enter instead.
- Month granularity. Crossings are rounded up to the next whole month.
- Data only. Indexes, snapshots, backups and free-space reserves are outside the forecast unless you include them in the inputs.
How to use the result
- Set the threshold to your action point, such as 75% of installed capacity, so the reported month is a deadline with slack.
- Subtract lead time. If adding storage takes six weeks of procurement and migration, start that long before the crossing.
- Forecast both models and plan against the earlier crossing.
- Re-run monthly with measured growth; the forecast is only as good as the rate you feed it, and a month of real data beats any assumption.
How it works
- Linear (GB per day, 30.44-day months) or compound (% per month) growth.
- Replication factor multiplies logical size to raw disk.
- Projects size at 3, 6, 12 and 24 months.
- Finds the first month raw size crosses your threshold, up to 10 years out.
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 and 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 sit in between, so forecast both to bracket your plan. Linear tends to under-predict a growing product, and compound can over-predict a mature one.
Why multiply by the replication factor?
Because the disk you must provision is the logical data times the number of copies you keep. A replication factor of 3 stores every byte three times across nodes for durability and availability, so 10 TB of logical data needs 30 TB of raw disk. Erasure coding usually needs a smaller multiplier, often around 1.4 to 1.5 times, but the principle is the same: plan for the physical footprint, not the logical size.
When will my disk fill up?
Find the month in which the raw size, logical data times replication, first reaches your capacity. With linear growth that is (capacity divided by replication, minus current size) divided by monthly growth. With this tool’s defaults, 500 GB growing 20 GB a day with three copies against 10 TB, the raw size passes 10 TB during the fifth month. The tool searches month by month for up to ten years and reports the first month at or over the line.
Where does retention fit in?
For append-only data with a retention window, growth is not unbounded: once the oldest data starts expiring, it leaves at roughly the rate new data arrives, and the size levels off. Keep everything forever and it grows without limit. This forecaster projects gross growth with no deletion. With a retention policy, the steady state is roughly ingest rate times the retention period times replication, which is often the number that actually matters.
What should I plan capacity against?
Not 100% of the disk. Databases and file systems degrade well before they are full, and you need room for compaction, temporary files, traffic spikes and the lead time to add hardware. A common rule is to act at 70 to 80% utilization. Set the threshold to that level, not to the raw disk size, and the month the forecaster reports becomes the date new capacity must be in place, rather than the day you actually run out.