# Database Storage Growth Projection Calculator

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

---

- **Canonical URL:** https://dothecalculation.com/calculators/database-storage-growth-calculator
- **Category:** AI & Tech Development
- **Publisher:** Do The Calculation (https://dothecalculation.com)
- **Cost:** Free, no account or sign-up required
- **Privacy:** Runs entirely in the browser; inputs are never sent to a server
- **Methodology:** https://dothecalculation.com/methodology

---

## How Big Will This Database Be in Three Years?

Project storage from rows and bytes rather than a growth percentage, then convert logical data into the disk you actually have to provision — replicas, headroom and all.

- Index overhead, compression, replicas and free-space headroom all counted
- A retention window turns unbounded growth into a steady state
- Runway in months against the storage you have provisioned today

## 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](/calculators/db-sharding-capacity-calculator) turns it into shard counts and node capacity, and the [PostgreSQL connection pool calculator](/calculators/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](/calculators/db-sharding-capacity-calculator) takes a projected total and works out shard divisions, node capacity and IOPS. The [PostgreSQL connection pool calculator](/calculators/postgresql-connection-pool-calculator) sizes the connection limit that usually becomes the constraint long before disk does, and the [Redis cluster memory calculator](/calculators/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](/calculators/cloud-storage-plan-comparison-calculator) compares plans on cost per TB.

## 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.

## 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.

## Related guides

- [Vector Database Sizing: Estimate RAM and Storage](https://dothecalculation.com/blog/tech/vector-db-storage-guide) — Estimate vector bytes, metadata payload, and simplified HNSW or IVF overhead—then validate RAM, disk, replicas, and headroom with your database.
- [How to Use Do The Calculation Calculators: A Practical Step-by-Step Guide](https://dothecalculation.com/blog/site-guides/how-to-use-calculators) — Learn the fastest reliable workflow for using Do The Calculation calculators, reading results, checking formulas, and using save, print, share, and export actions correctly.

## Related calculators

- [B-Tree/LSM Index RAM & Disk Overhead Calculator](https://dothecalculation.com/calculators/database-indexing-overhead-calculator) — Calculate indexing overhead size, storage requirements, and RAM block caches for B-Tree and LSM database engines instantly.
- [Encryption Key Strength (bits) Calculator](https://dothecalculation.com/calculators/encryption-key-strength-calculator) — Convert a key size into bits of security strength using the NIST comparable strengths table.
- [Git Repo Size & LFS Cost Calculator](https://dothecalculation.com/calculators/git-repo-size-cost-calculator) — Price Git LFS storage and bandwidth against your plan allowance and project the bill as the repo grows.
- [Cloud Storage Plan Cost Comparison Calculator](https://dothecalculation.com/calculators/cloud-storage-plan-comparison-calculator) — Compare cloud storage plans on cost per TB, cost per GB you actually store, and five-year total.
- [Compression Ratio Calculator](https://dothecalculation.com/calculators/compression-ratio-calculator) — Convert between compression ratio and space saved, and price the storage and transfer time it buys.
- [Database Sharding & Capacity Planner](https://dothecalculation.com/calculators/db-sharding-capacity-calculator) — Model database shard divisions, estimate node capacity, replication storage footprints, and IOPS requirements instantly for free.

---

_This is plain arithmetic with no vendor assumptions: rows times bytes, grossed up for indexes, divided by compression, multiplied by replicas, and divided by a free-space target. Gigabytes are decimal, matching how storage is sold. It models one table or one uniform workload, so a mixed database should be projected table by table. It does not model write-ahead logs, backups, temporary sort space, replication slots, or table bloat, all of which consume real disk. Measure row size and compression ratio from your own database rather than accepting defaults, and treat the runway figure rather than the eventual total as the output that matters._

---

_Source: [Do The Calculation](https://dothecalculation.com/calculators/database-storage-growth-calculator). Quote freely with attribution and a link to this page._