Database Sizing Calculator
Estimate database storage, IOPS, and RAM requirements from row count and query patterns.
About this calculator
This calculator estimates storage, IOPS, RAM, and connection pool sizing for a relational database from schema-level facts you likely already know: row count, average row size, and index count. Raw data size comes straight from multiplying rows by row size; index overhead is added on top as a percentage of that raw size per index, reflecting how B-tree indexes typically add roughly 20-40% each depending on cardinality and key width. A flat 10% is reserved for the write-ahead log and transaction buffer that active databases maintain, and the whole thing is then multiplied by your replication factor to get total storage across the cluster, not just a single instance. IOPS is split into reads and writes and weighted separately — reads get a 20% markup for cache misses that bypass buffer pool hits, while writes get a 2.5x factor because each write typically generates both a WAL entry and a data page write.
The RAM recommendation follows the common "working set in memory" rule of thumb: 20% of your data plus all your indexes, with a 10% buffer, should fit in RAM so hot rows and indexes stay cached rather than hitting disk. Connection pool size uses a square-root heuristic against combined read/write throughput — a common starting point, though the right number ultimately depends on your database engine's connection overhead. The 12-month projection compounds your monthly growth rate forward, useful for right-sizing storage before you provision rather than after you fill the disk.
Inputs
Results
Total storage needed (GB)
12.4
Required IOPS
1,450
Recommended RAM (GB)
5
How to Use This Calculator
- Enter the Total Row Count and Average Row Size (bytes) for your primary table.
- Input the number of Indexes and their Index Size % of data overhead.
- Set Reads per Second and Writes per Second from your application metrics.
- Enter Monthly Growth Rate % and Replication Factor.
- Review Total Storage Needed (GB) and Total IOPS to select the right database instance size.
How the result changes with Total row count
| Total row count | Total storage needed (GB) | Required IOPS | Recommended RAM (GB) |
|---|---|---|---|
| 5,000,000 | 6.2 | 1,450 | 3 |
| 7,500,000 | 9.3 | 1,450 | 4 |
| 15,000,000 | 18.6 | 1,450 | 7 |
| 25,000,000 | 30.99 | 1,450 | 12 |
What each input means
- Total row count
- Total number of rows across primary tables.
- Avg row size (bytes)
- Average size of a single row including all columns (typically 100-1000 bytes).
- Number of indexes
- Total secondary indexes across tables.
- Index size % of data
- Each index adds this percentage of the data size (B-tree ~20-40%).
- Reads per second
- Average read queries per second hitting the database.
- Writes per second
- Average INSERT/UPDATE/DELETE operations per second.
- Monthly growth rate %
- Expected monthly data growth rate.
- Replication factor
- Number of data copies (1 = no replication, 2 = primary + 1 replica).
What each result means
- Total storage needed (GB)
- Total disk space including data, indexes, WAL, and replication.
- Required IOPS
- Estimated IOPS needed to handle read + write load.
- Recommended RAM (GB)
- RAM needed to keep working set and indexes in memory.
- Raw data size (GB)
- Data size before indexes and overhead.
- Index overhead (GB)
- Space consumed by all secondary indexes.
- Single instance storage (GB)
- Total per-instance storage (data + indexes + WAL).
- Connection pool size
- Recommended database connection pool size.
- Storage in 12 months (GB)
- Projected total storage after 12 months of growth.
How this is calculated
Worked example, using the default values
- Identify Input Parameters4 parametersTotal row count = 10000000, Avg row size (bytes) = 256, Number of indexes = 5, Index size % of data = 30 = 8 input(s) provided
- Calculate Total storage neededTotal storage needed = singleInstanceGB * replicationFactor12.4 = 12.4
- Calculate Required IOPSRequired IOPS = readIOPS + writeIOPS1450 = 1450
- Calculate Recommended RAMRecommended RAM = max(15 = 5
- Calculate Raw data sizeRaw data size = (rowCount * avgRowSizeBytes) / (1024 * 1024 * 1024)2.38 = 2.38
- Calculate Index overheadIndex overhead = rawDataGB * (indexCount * (indexOverheadPct / 100))3.58 = 3.58
Engine last updated . Checked against 2 independently-derived tests — how we verify calculators. Built by Paul Gunder, a software engineer, not a licensed financial, medical, or legal professional.
Frequently Asked Questions
Why does the recommended RAM only cover 20% of raw data plus indexes, not the whole database?
recommendedRAMGB follows the working-set-in-memory heuristic: most workloads only touch a hot subset of their data regularly, so the calculator sizes RAM at rawDataGB × 0.2 plus the full indexOverheadGB (since indexes get hit on nearly every query) with a 10% buffer on top. It deliberately doesn't try to fit 100% of raw data in memory — that would usually be far more RAM than a typical access pattern needs.
Why do writes carry a 2.5x IOPS multiplier while reads only carry 1.2x?
The calculator assumes reads are mostly served from cache or hit a single index lookup with a modest 20% overhead for cache misses, while every write (INSERT/UPDATE/DELETE) typically triggers both a write-ahead log entry and a data page write to disk — two physical I/O operations for one logical write, hence writeIOPS = writesPerSecond × 2.5 versus readIOPS = readsPerSecond × 1.2.
How does the replication factor affect total storage versus just adding more disks?
totalStorageGB is singleInstanceGB (raw data + index overhead + WAL buffer) multiplied straight through by replicationFactor, so a replication factor of 3 means you need three full independent copies of the entire dataset across the cluster, not just extra headroom on one instance. This is why the calculator separately reports singleInstanceGB — it's the number you'd budget per node, while totalStorageGB is the cluster-wide total.
Why might my actual index overhead be higher or lower than what this calculator estimates?
indexOverheadGB is a linear estimate: rawDataGB × indexCount × (indexOverheadPct / 100), treating every index as adding the same fixed percentage of data size. Real B-tree index size actually depends heavily on column cardinality and key width — a composite index on several wide text columns can be far larger than 30% of the table, while a single narrow integer index can be much smaller, so treat the 20-40% range in the helpText as a starting estimate to adjust once you know your actual schema.
Related Calculators
The questions that sit next to this one — chosen by subject, including calculators filed under a different category.
Server Sizing Calculator
Calculate CPU, RAM, storage, and instance count from workload requirements.
DevopsCloud Cost Calculator
Estimate monthly cloud infrastructure costs from compute, storage, and data transfer.
DevopsCI/CD Pipeline Cost Calculator
Calculate total CI/CD cost including platform fees and developer wait time.
More in Technology & Computing.