tech calculator

Database Storage Growth Projection Calculator

Project database size from rows and bytes, then convert it into the disk you actually have to provision.

Monthly growth = rows x bytes per row x (1 + index overhead) / compression. Provisioned disk = logical size x replicas / (1 - free space headroom). A 420 GB database taking 45 million 512-byte rows a month with 35% index overhead and 3:1 compression reaches 1,225 GB logical in three years and needs 3,265 GB provisioned.

Quick actions: Save inputs, view saved runs, print, share, or export results

Saved Runs

Inputs

Current Database SizeGB

Projection Horizonmonths

New Rows per Month

Average Row Sizebytes

Index Overhead%

Row Growth per Month%

Compression Ratio: 1

Retention Window (0 = keep everything)months

Copies (primary + replicas)

Free Space Headroom%

Currently Provisioned StorageGB

Cost per GB-Month$

Results

Logical Size at Month 36

1224.5 GB

Effective Bytes per Row230.4 bytes on disk

First Month Added10.37 GB

Growth Over the Horizon804.5 GB

Growth Multiple2.92x

Provisioned Storage Needed3265.4 GB

Steady Statenever reached — no retention window set

Runway on Current Disk21 months

Storage Cost Now$131.98 per month

Storage Cost at Month 36$375.53 per month

Total Over 36 Months$8,190.09

Tip

Useful when a capacity request needs a number behind it, when a retention policy is being argued about, and whenever someone asks how long the current volume will last.

Formula

Storage growth projection

Rows in month n     = base rows x (1 + growth %)^(n - 1)
GB added in month n = Rows x Bytes per row x (1 + index %) / Compression / 1e9
Logical size        = previous size + GB added - GB evicted by retention
Provisioned size    = Logical size x Replicas / (1 - Headroom %)
Monthly cost        = Provisioned size x Cost per GB-month

Index overhead is applied to the raw row size, compression divides what actually lands on disk, and the retention window evicts whatever arrived more than N months ago. Replicas and free-space headroom then convert logical data into the disk you have to buy — the number that matters for capacity planning, and typically twice the logical figure or more.

Step by step

How the calculation works

1Start from rows and bytes rather than from a growth percentage. A percentage hides whether growth is driven by more users, more events per user, or wider rows, and those three fail differently. Measuring average row size from your own table statistics takes a minute and makes every other number here trustworthy.
2Index overhead is the input people leave out. Secondary indexes, primary key structures, and per-row metadata routinely add 25 to 50 percent on top of the raw data, and on a heavily indexed table they can exceed the data itself. If you do not know yours, measure it once against a real table.
3Compression and replication pull in opposite directions and both belong in the estimate. A 3x compression ratio and two replicas roughly cancel out; add a 25 percent free-space target on top and the disk you provision is about 90 percent of the uncompressed logical size, not a third of it.
4A retention window is the difference between a projection that levels off and one that does not. With no retention, a table that ingests 10 GB a month has no upper bound. With 24 months of retention, it converges: everything older falls out at the same rate new data arrives, and the runway question stops being urgent.
5The runway figure is the one to put in a planning document. Knowing you have 21 months before the current volume is full is actionable; knowing the database will be 1.2 TB eventually is not. Re-run this whenever ingest changes materially rather than treating it as a one-off.
6For the layers around this: the [database sharding and capacity planner](/calculators/db-sharding-capacity-calculator) turns a total into a node count, the [Redis cluster memory calculator](/calculators/redis-cluster-memory-calculator) sizes the cache in front of it, and the [PostgreSQL connection pool calculator](/calculators/postgresql-connection-pool-calculator) covers the other resource that runs out first.

Related guides

Learn more about this calculation

Guide

Vector Database Sizing: Estimate RAM and Storage

Estimate vector bytes, metadata payload, and simplified HNSW or IVF overhead—then validate RAM, disk, replicas, and headroom with your database.

Guide

How to Use Do The Calculation Calculators: A Practical Step-by-Step Guide

Learn the fastest reliable workflow for using Do The Calculation calculators, reading results, checking formulas, and using save, print, share, and export actions correctly.

Tech Tool

Database Sharding & Capacity Planner

Turn a projected total into shard counts, node capacity, and IOPS requirements.

Tech Tool

Redis Cluster Memory Calculator

Size the cache tier that sits in front of the database.

Tech Tool

PostgreSQL Connection Pool Calculator

The other capacity ceiling: connections, not gigabytes.

tech calculator

Database Storage Growth Projection Calculator

Project database size from rows and bytes, then convert it into the disk you actually have to provision.

Quick actions: Save inputs, view saved runs, print, share, or export results

Saved Runs

Inputs

Current Database SizeGB

Projection Horizonmonths

New Rows per Month

Average Row Sizebytes

Index Overhead%

Row Growth per Month%

Compression Ratio: 1

Retention Window (0 = keep everything)months

Copies (primary + replicas)

Free Space Headroom%

Currently Provisioned StorageGB

Cost per GB-Month$

Results

Logical Size at Month 36

1224.5 GB

Effective Bytes per Row230.4 bytes on disk

First Month Added10.37 GB

Growth Over the Horizon804.5 GB

Growth Multiple2.92x

Provisioned Storage Needed3265.4 GB

Steady Statenever reached — no retention window set

Runway on Current Disk21 months

Storage Cost Now$131.98 per month

Storage Cost at Month 36$375.53 per month

Total Over 36 Months$8,190.09

Tip

Useful when a capacity request needs a number behind it, when a retention policy is being argued about, and whenever someone asks how long the current volume will last.

Summary

Key output metrics

Logical Size at Month 36

1225 GB

2.92x today's size

Disk to Provision

3265 GB

2 copies plus 25% free space

Runway

21 months

against 2,000 GB provisioned

D3 visualization

Provisioned Storage Required

Logical data multiplied by replica count and grossed up for free-space headroom, month by month across the projection.

Guide

How to understand and use this calculator

Quick Answer — How Do You Project Database Storage Growth?

Start from rows and bytes, not from a percentage. A growth percentage hides whether the driver is more users, more events per user, or wider rows, and those three behave differently and fail differently. Row count times average row size, grossed up for indexes and divided by compression, is a number you can defend.

Then convert logical data into provisioned disk, because they are not the same thing and the gap is large. Replicas multiply it; a free-space target divides it.

A 420 GB database ingesting 45 million rows a month at 512 bytes each, with 35 percent index overhead, 4 percent monthly row growth, 3:1 compression, two copies and a 25 percent free-space target:

Effective size on disk per row — 230.4 bytes
First month added — 10.37 GB
Logical size at 36 months — 1,225 GB, a 2.92× increase
Provisioned storage needed — 3,265 GB
Runway on 2,000 GB of current storage — 21 months
Storage cost at $0.115 per GB-month — $131.98 now, $375.53 by month 36

Note the ratio at the end: 1,225 GB of logical data needs 3,265 GB of disk. That factor of 2.7 is the number capacity requests get wrong.

How to Use This Calculator: A 420 GB Production Database

Enter the current size and the ingest. 45 million rows a month at 512 bytes is a busy but ordinary event or transaction table. Measure the row size from your own table statistics rather than adding up column widths — real rows carry per-row headers, null bitmaps, and alignment padding that a schema does not show.

Add index overhead. At 35 percent, each 512-byte row costs 691 bytes with its indexes. Then apply compression: at 3:1 the figure lands at 230.4 bytes actually written to disk. Those two inputs pull hard in opposite directions and leaving either one out throws the projection off by a factor of two.

Set the growth rate on rows rather than on gigabytes. At 4 percent a month, month one adds 10.37 GB and month 36 adds substantially more, which is why the projection curves upward rather than running straight.

Now the multipliers that turn data into hardware. Two copies — a primary and one replica — and a 25 percent free-space target, because a database running at 100 percent utilisation cannot vacuum, rebuild an index, or take a snapshot. Logical data of 1,225 GB becomes 3,265 GB of provisioned storage.

Finally, enter what you have provisioned. Against 2,000 GB, the calculator reports 21 months of runway. That is the number to take to a planning meeting — not the eventual size, which nobody can act on.

The Formulas This Calculator Uses

Rows in month n = base rows × (1 + growth %)^(n − 1).

GB added in month n = Rows × Bytes per row × (1 + index %) ÷ Compression ÷ 10⁹.

Logical size = previous size + GB added − GB evicted by the retention window.

Provisioned size = Logical size × Replica count ÷ (1 − Headroom %).

Monthly cost = Provisioned size × Cost per GB-month.

The retention window works by remembering what each month contributed and dropping it once it ages out, which is what makes a steady state emerge naturally rather than being asserted. With no retention, the projection has no upper bound at all.

Gigabytes here are decimal — 10⁹ bytes — because that is how storage is sold and billed. A filesystem reporting binary gibibytes will show roughly 7 percent less for the same data.

A Second Example: What a Retention Policy Is Worth

Take the same 420 GB database and add a 24-month retention window, so anything older than two years is dropped.

Logical size at 36 months falls from 1,225 GB to 1,069 GB, and provisioned storage falls from 3,265 GB to 2,850 GB. Total storage spend across the three years drops from $8,190 to $7,902.

The saving looks modest and the shape change does not. Without retention the curve keeps climbing; with it, the database converges on a steady state where data ages out at the same rate new data arrives. The runway question stops being a recurring emergency.

A smaller case for contrast. A 12 GB application database taking 800,000 rows a month at 280 bytes, with 25 percent index overhead, 2 percent monthly growth, no compression, a single copy and 20 percent headroom, reaches 20.52 GB of logical data after two years and needs 25.65 GB provisioned. Total storage cost across 24 months at $0.10 per GB-month is $48.30.

That is the useful comparison. The same arithmetic that justifies a serious capacity project at one scale shows that at another scale storage is not worth a meeting.

Where Storage Projections Usually Go Wrong

Leaving out indexes. This is the most common error and the largest. Dropping index overhead from the example takes the 36-month logical figure from 1,225 GB to 1,016 GB — a 17 percent understatement, and on a heavily indexed table the indexes can exceed the data outright.

Confusing logical data with provisioned disk. After two copies and a 25 percent free-space target, provisioned storage is about 89 percent of the uncompressed logical size even at 3:1 compression. Teams that budget for the compressed figure run out of disk.

Assuming linear growth. Row counts usually grow with the business, so ingest compounds rather than staying flat. Four percent a month is 60 percent a year, and over three years it more than quadruples the monthly ingest.

Forgetting free space. A database at 95 percent utilisation cannot vacuum properly, cannot rebuild an index in place, and cannot take a snapshot. The headroom is not waste; it is what keeps maintenance operations possible.

Planning the total rather than the runway. The eventual size is not actionable. Months until the current volume fills is, and it is the only output of this calculator that changes what anyone does on Monday.

Once you have a total, the database sharding and capacity planner turns it into shard counts and node capacity, and the PostgreSQL connection pool calculator covers the resource that usually runs out first.

Limitations

This models one table or one uniform workload. A real database is a mixture of tables with different row sizes, index profiles, compression behaviour and growth rates, and projecting the whole thing as a single average will be wrong in the details. For anything important, run the calculator per table and add the results.

Compression is treated as a constant ratio. Real compression varies with the data, degrades as tables fragment, and differs sharply between row-store and column-store engines. Measure your own ratio rather than accepting a vendor headline.

Deletions are only modelled through the retention window. Application-level deletes, archival jobs, and partition drops all reduce size in ways this does not see. And in most engines a delete does not immediately return space to the filesystem — it returns it to the table's free space map, which is a different thing.

Nothing here models write-ahead logs, backups, temporary sort space, replication slots, or bloat from long-running transactions. All of those consume real disk on a production system, and none of them appear in a row-and-byte projection.

Related Calculators

Storage is one dimension of database capacity and rarely the first to bind. The database sharding and capacity planner takes a projected total and works out shard divisions, node capacity and IOPS. The PostgreSQL connection pool calculator sizes the connection limit that usually becomes the constraint long before disk does, and the Redis cluster memory calculator sizes the cache tier that keeps read traffic off the primary. For the cost of the storage itself once you know how much you need, the cloud storage plan comparison calculator compares plans on cost per TB.

Related concepts

Index Overhead

The storage secondary indexes and per-row structures add on top of the data itself, commonly 25 to 50 percent and sometimes more than the table.

Provisioned vs Logical

Logical data multiplied by replica count and grossed up for free-space headroom. It is the disk you buy, and typically two to three times the logical figure.

Retention Window

A policy dropping data older than N months. It is what turns an unbounded growth curve into a steady state where eviction matches ingest.

Frequently Asked Questions

How do I project database storage growth?+

Multiply new rows per month by average row size, add index overhead, divide by your compression ratio, and compound the row count by whatever growth rate the business is running at. Then multiply by replica count and divide by one minus your free-space target to get the disk you actually have to provision.

How much do indexes add to database size?+

Commonly 25 to 50 percent on top of the raw data, and on a heavily indexed table more than the data itself. In the worked example, dropping 35 percent index overhead takes the three-year logical projection from 1,225 GB to 1,016 GB — a 17 percent understatement from leaving out one input.

Why is provisioned storage so much larger than my data?+

Because replicas multiply it and free-space headroom divides it. In the example, 1,225 GB of logical data with two copies and a 25 percent free-space target needs 3,265 GB of disk — a factor of 2.7. Budgeting for the logical figure is the most common way capacity requests come up short.

How much free space should a database have?+

Enough to vacuum, rebuild an index in place, and take a snapshot, which in practice means 20 to 30 percent for most engines. A database running near full utilisation cannot perform its own maintenance, and that is how a capacity problem becomes an availability problem.

What does a retention policy actually save?+

Less than people expect in gigabytes and more than they expect in shape. Adding 24-month retention to the example database cuts the three-year figure from 1,225 GB to 1,069 GB and the three-year cost from $8,190 to $7,902. The real benefit is that the database converges on a steady state instead of growing without bound.

Should I use a growth percentage instead of rows and bytes?+

Only as a sanity check. A percentage cannot tell you whether growth comes from more users, more events per user, or wider rows, and it cannot be reconciled against anything you can measure. Row counts and average row size come straight out of table statistics and can be checked next quarter.

How do I measure average row size?+

From the database, not from the schema. Every major engine exposes table size and row count in its system catalogs, and dividing one by the other gives you the real figure including per-row headers, null bitmaps and alignment padding. Adding up declared column widths reliably understates it.

Does this account for backups and write-ahead logs?+

No. It projects table and index data only. Write-ahead logs, backups, temporary sort space, replication slots and bloat from long-running transactions all consume real disk on a production system and none of them appear in a row-and-byte projection. Add them separately before sizing a volume.

Formula

Storage growth projection

Rows in month n     = base rows x (1 + growth %)^(n - 1)
GB added in month n = Rows x Bytes per row x (1 + index %) / Compression / 1e9
Logical size        = previous size + GB added - GB evicted by retention
Provisioned size    = Logical size x Replicas / (1 - Headroom %)
Monthly cost        = Provisioned size x Cost per GB-month

Step by step

How the calculation works

1Start from rows and bytes rather than from a growth percentage. A percentage hides whether growth is driven by more users, more events per user, or wider rows, and those three fail differently. Measuring average row size from your own table statistics takes a minute and makes every other number here trustworthy.
2Index overhead is the input people leave out. Secondary indexes, primary key structures, and per-row metadata routinely add 25 to 50 percent on top of the raw data, and on a heavily indexed table they can exceed the data itself. If you do not know yours, measure it once against a real table.
3Compression and replication pull in opposite directions and both belong in the estimate. A 3x compression ratio and two replicas roughly cancel out; add a 25 percent free-space target on top and the disk you provision is about 90 percent of the uncompressed logical size, not a third of it.
4A retention window is the difference between a projection that levels off and one that does not. With no retention, a table that ingests 10 GB a month has no upper bound. With 24 months of retention, it converges: everything older falls out at the same rate new data arrives, and the runway question stops being urgent.
5The runway figure is the one to put in a planning document. Knowing you have 21 months before the current volume is full is actionable; knowing the database will be 1.2 TB eventually is not. Re-run this whenever ingest changes materially rather than treating it as a one-off.
6For the layers around this: the [database sharding and capacity planner](/calculators/db-sharding-capacity-calculator) turns a total into a node count, the [Redis cluster memory calculator](/calculators/redis-cluster-memory-calculator) sizes the cache in front of it, and the [PostgreSQL connection pool calculator](/calculators/postgresql-connection-pool-calculator) covers the other resource that runs out first.

Related guides

Learn more about this calculation

Guide

Database Storage Growth Projection Calculator

Inputs

Results

Storage growth projection

How the calculation works

Learn more about this calculation

Vector Database Sizing: Estimate RAM and Storage

How to Use Do The Calculation Calculators: A Practical Step-by-Step Guide

Database Sharding & Capacity Planner

Redis Cluster Memory Calculator

PostgreSQL Connection Pool Calculator

Key facts

Database Storage Growth Projection Calculator

Inputs

Results

Key output metrics

Provisioned Storage Required

How to understand and use this calculator

Quick Answer — How Do You Project Database Storage Growth?

How to Use This Calculator: A 420 GB Production Database

The Formulas This Calculator Uses

A Second Example: What a Retention Policy Is Worth

Where Storage Projections Usually Go Wrong

Limitations

Related Calculators

Related concepts

Frequently Asked Questions

Storage growth projection

How the calculation works

Learn more about this calculation

Vector Database Sizing: Estimate RAM and Storage

How to Use Do The Calculation Calculators: A Practical Step-by-Step Guide

Database Sharding & Capacity Planner

Redis Cluster Memory Calculator

PostgreSQL Connection Pool Calculator

Key facts

Key output metrics

Provisioned Storage Required

How to understand and use this calculator

Quick Answer — How Do You Project Database Storage Growth?

How to Use This Calculator: A 420 GB Production Database

The Formulas This Calculator Uses

A Second Example: What a Retention Policy Is Worth

Where Storage Projections Usually Go Wrong

Limitations

Related Calculators

Related concepts

Frequently Asked Questions