Database Storage Growth Cost Calculator

Database storage growth is a forecasting problem, not a snapshot of today's size

This page is about slope and horizon. Most teams know current size, but the real budgeting question is how fast the dataset grows and what average size they will actually pay for over the next few months, not just where the database ends up on the last day of the period.

• Starting size: the current stored baseline before growth compounds over the chosen horizon.
• Growth slope: the daily or weekly expansion that determines average paid GB more than the end number alone.
• Horizon: the planning window that decides whether growth is a minor drift or a real budget problem.

Where database-growth estimates usually drift

• Only current size is tracked, so the budget ignores how much average GB rises during the month.
• Growth is assumed linear forever even though launches, retention changes, or new indexes can change the slope quickly.
• Raw table growth is modeled, but replicas, indexes, or backup policy make total paid storage grow faster.
• One short healthy period is used as the growth baseline even though imports or product changes are coming next.

What to review before trusting the growth forecast

• Use average GB as the budgeting lens instead of only talking about end-of-month size.
• Check whether indexes, replicas, or retention policy changes should raise the effective storage multiplier.
• Model a launch or backfill scenario if the next quarter is not expected to look like the last month.
• Keep backup and retained-history growth close by so the page does not understate total storage economics.

Baseline vs accelerated-growth scenarios

How to review the first real growth period

• Compare forecasted average GB against actual paid GB-month instead of only checking the latest size snapshot.
• Review whether the miss came from slope change, replica/index growth, or retention-related storage before changing the whole model.

Next steps