{{ result.summaryTitle }}
{{ result.primaryDisplay }}
{{ result.secondaryText }}
{{ badge.label }}
{{ layerStageUtilizationLabel }}
Pick a starting point for OLTP, analytics, managed cloud, or compliance storage growth.
Choose the closest engine family so overhead and maintenance guardrails match the workload.
Use the current table/data-file footprint for one primary database or shard.
{{ formatPercent(params.monthly_growth_pct, 1) }}
Use measured storage growth over the last 30-90 days when available.
%
Select the horizon that matches procurement or reserved-capacity review cycles.
{{ formatPercent(params.index_overhead_pct, 0) }}
Use observed index/data ratio, or start with 30-60% for B-tree heavy transactional schemas.
%
{{ formatPercent(params.wal_daily_pct, 1) }}
Use archive-log or WAL metrics; write-heavy systems can exceed the data growth rate many times over.
%
Model the retained recovery window, including log backups needed to replay to any point in that window.
days
Count independent storage copies for read replicas, HA standbys, or cross-region replicas.
copies
Enter current primary allocation, not backup repository size. Use 0 to skip runway warnings.
{{ formatPercent(params.fill_threshold_pct, 0) }}
Use 70-80% for production databases unless your platform enforces a separate reserve.
%
Optional handoff label; it does not change the math.
Use observed bloat or leave the profile default for a conservative planning pass.
%
Keep this outside steady table/index bytes so maintenance jobs do not collide with growth.
%
A value of 1.5 means the modeled data/index layer is divided by 1.5.
x:1
Managed snapshot billing can differ from export backups; use your observed backup storage metric when possible.
x:1
Raise this for slow archiving, replication lag, migration slots, or delayed standby windows.
hours
Use 0 for one retained backup set, 1 for a second geo/immutable copy, and so on.
extra
Set 0 to skip the max-allocation guardrail.
Leave 0 to omit cost pressure from recommendations.
$ /GiB-mo
{{ header }} Copy
{{ cell }}
{{ header }} Copy
{{ cell }}
{{ header }} Copy
{{ cell }}
Tags: Database, Devops, Storage
Customize
Advanced
:

Database storage growth is rarely just table growth. A production database also carries indexes, page overhead, write-ahead or transaction logs, maintenance workspace, bloat reserve, retained backups, replica copies, and unused headroom. When those parts are ignored, a cluster can look comfortable while the next index build, replay delay, or backup-retention change pushes it toward an allocation limit.

The planning problem is a runway problem. Current data size tells only where the forecast starts. Monthly growth, retention policy, replica count, compression, and fill threshold decide when the primary allocation becomes tight and how large the wider estate becomes by the end of the horizon.

Database storage band showing data files, indexes, logs, backups, replicas, headroom, and a fill-threshold marker.

Different engines expose the same pressure with different names. PostgreSQL has WAL, MySQL and InnoDB use redo and binary logs, and SQL Server has a transaction log plus tempdb and recovery-model behavior. The practical question is still similar: how much primary space is needed for steady operation, and how much surrounding storage is needed for recovery, replicas, and cost planning?

Fill thresholds are not cosmetic. Production databases need unused space for checkpoints, vacuum or purge lag, index rebuilds, sort spills, log bursts, and emergency operations. A primary volume planned to run at 95 percent full may be cheaper on paper, but it leaves little room for the maintenance events that usually happen during stressful periods.

Storage forecasts are strongest when they are tied to measured growth and real retention settings. A one-time export size, a dashboard total, and a cloud bill can each count different things, so the same environment may have several true numbers depending on whether the question is primary data, allocated volume, backup footprint, or estate cost.

How to Use This Tool:

Start with the primary database or shard you want to size, then add the operational parts that grow with it.

  1. Choose Sizing profile and Database engine. The profile loads a realistic starting point, while the engine changes page-overhead, local-log, and maintenance wording assumptions.
  2. Enter Current data files and Monthly table data growth. The growth rate compounds month by month before dependent storage parts are recalculated.
  3. Set the Forecast horizon, Index overhead, Daily WAL/log generation, Backup retention, Replica count, and Provisioned storage.
  4. Use Fill threshold to set the target primary utilization. For production databases, 70 to 80 percent is a common planning range because maintenance needs working space.
  5. Open Advanced when the default reserves are too coarse. Adjust bloat reserve, temp workspace, primary compression, backup compression, local log retention hours, extra backup copies, autoscale maximum, and blended storage cost.
  6. Read Forecast Ledger and Storage Layers before acting on the summary. Then use Runway Actions, Primary Runway Curve, and Layer Footprint Mix to identify the part driving the decision.

If the input review appears, fix the highlighted values first. Compression ratios must be at least 1, the fill threshold must be greater than zero, and size fields should describe one primary database or a clearly bounded shard group.

Interpreting Results:

Forecast target reports the primary target at the end of the selected horizon. The secondary line adds the estate footprint, which includes primary target, retained backups and logs, and replica copies. When cost is provided, the monthly run rate follows that wider estate footprint rather than only primary storage.

Result view Read first Verification cue
Forecast Ledger Checkpoint, Primary target, Data files, Indexes, WAL/log, Backups, Estate, Cost/mo, and Alloc use. Compare the final month with the month where allocation or autoscale limits are crossed.
Storage Layers Data files, Indexes, MVCC/table bloat, Temp workspace, Local WAL/log reserve, Primary headroom, Backups, and Replicas. Look for a storage part growing faster than table data.
Runway Actions Primary allocation, WAL/log pressure, Backup retention, Replica copies, Autoscale maximum, and Monthly run rate. Act on High or warning statuses before the threshold month.
Primary Runway Curve Primary target over each forecast month with provisioned storage where entered. Use the curve to time expansion, not only to size the final state.
Layer Footprint Mix The final estate split across primary data, indexes, operational reserve, headroom, backups, and replicas. Check whether retention or replicas are the budget driver.

A green runway does not mean the database is operationally healthy. It means the modeled storage stays below the selected threshold for the selected horizon. Verify write rate, archive throughput, replica lag, backup restore tests, and provider-specific limits separately.

If Provisioned storage is set to zero, runway warnings become sizing guidance rather than allocation warnings. If Autoscale maximum is set, an autoscale cap can become the binding limit even when the current provisioned allocation has not been crossed yet.

Technical Details:

The forecast compounds logical table data first, then recalculates every dependent storage part from that grown base. This matters because an index percentage, a WAL percentage, and a backup-retention rule should scale with the future data set, not only with the current one.

Primary target is deliberately larger than steady primary bytes. Steady primary bytes include compressed data files, indexes, bloat reserve, temp workspace, and local log reserve. Dividing by the fill-threshold fraction creates the target allocation that leaves unused capacity at the planned utilization limit.

Formula Core:

The core forecast uses compounded data growth, percentage-based overheads, retained log windows, and the selected fill threshold.

Dm = D0⁢(1+g)m data files = Dm+page overheadprimary compression steady primary = data files + indexes + bloat + temp + local log reserve primary target = steady primaryfill threshold fraction

For example, 8 TiB of current data growing at 6 percent monthly reaches about 32.34 TiB after 24 months. With 45 percent index overhead, 18 percent bloat reserve, 10 percent temp workspace, 8 percent daily log generation, 24 hours of local log retention, no primary compression, and an 80 percent fill threshold, the primary target is much larger than the grown data files alone.

Term How it is modeled Why it matters
Indexes Percentage of grown table data, adjusted by the primary compression ratio. Covering and reporting indexes can rival table-data growth.
MVCC/table bloat Percentage reserve outside compressed data and indexes. Dead tuples, purge lag, page splits, and maintenance delay consume primary space.
Temp workspace Percentage reserve for sorts, checks, rebuilds, and similar maintenance work. Large operations need scratch space before they improve the storage situation.
Local WAL/log reserve Daily log generation scaled by retained local hours, with an engine minimum. Archive delays, replication slots, or transaction-log backup gaps can fill disks quickly.
Backups and retained logs Backup base plus retained log archive, adjusted by backup compression and extra copies. Point-in-time recovery windows can become a storage and cost driver.
Replica copies Replica count multiplied by data, indexes, bloat, and local log reserve. High availability and regional copies multiply the operational footprint.

Estate footprint combines the primary target, backup set, and replicas. Monthly cost multiplies that estate footprint in GiB by the entered blended cost per GiB-month. Decimal units and binary units are both accepted, so keep GB/TB and GiB/TiB choices consistent when comparing against bills or storage-console metrics.

Accuracy Notes:

This is a planning estimate. It does not inspect live database files, storage-provider billing records, backup catalogs, or replica lag.

  • Use measured growth from database metrics when available instead of a single recent export size.
  • Keep compression and backup-compression settings conservative until real storage reports confirm them.
  • Validate log generation during write-heavy periods, not only during normal traffic.
  • Check restore tests and recovery objectives separately from storage capacity.

Worked Examples:

PostgreSQL HA growth review. An 8 TiB primary with 6 percent monthly growth, 45 percent index overhead, 8 percent daily WAL, 14 days of backup retention, one replica, 10 TiB provisioned storage, an 80 percent fill threshold, 18 percent bloat reserve, and 24 hours of local WAL retention can show Runway 0 months when the modeled steady primary bytes already exceed the threshold. Runway Actions should be used before the final forecast month.

Analytics warehouse growth. A 22 TiB analytics warehouse with 9 percent monthly growth over 36 months, lower WAL percentage, 30 days of retention, no replicas, primary compression, backup compression, and one extra backup copy may have primary runway but a large Layer Footprint Mix from backups. In that case, retention and archive cost need review before adding primary storage alone.

Autoscale ceiling issue. If Provisioned storage is 6 TiB and Autoscale maximum is 8 TiB, a forecast primary target above 8 TiB makes the autoscale cap a blocker even when current utilization still looks safe. Raise the cap, reduce growth assumptions with real evidence, or schedule a storage expansion before the listed autoscale runway.

FAQ:

Should current data include indexes?

No. Current data files should describe logical table or data-file footprint before index overhead is added. Use Index overhead for index space so the forecast can show data and index growth separately.

Why is primary target larger than steady primary storage?

The primary target divides steady primary storage by the Fill threshold. At an 80 percent threshold, 8 TiB of steady primary storage needs a 10 TiB target to leave planned headroom.

What should I do if WAL or transaction logs are high?

Check archive throughput, transaction-log backup cadence, replication slots, delayed standby settings, and write bursts. The Runway Actions row explains whether log reserve is a High or Watch item.

Can this replace cloud-provider storage metrics?

No. Use it to model scenarios from known assumptions, then compare the result with provider metrics, database catalog queries, backup storage, and billing records.

Why do GB and GiB results differ?

GB and TB use powers of 1000. GiB, TiB, and PiB use powers of 1024. Match the unit to the database report, storage console, or invoice before comparing numbers.

Glossary:

WAL
Write-ahead logging, the PostgreSQL log stream used for crash recovery and replication.
Transaction log
A database log that records changes needed for recovery, rollback, and point-in-time restore.
Point-in-time recovery
Restoring a database to a chosen time by combining a backup with retained log records.
Replica
A read, high-availability, or regional copy that requires its own storage allowance.
Fill threshold
The planned maximum utilization before the primary allocation is considered too full.
Estate footprint
The modeled total of primary target, backups, retained logs, and replicas.

References: