Database Sizing Workbench
What does a database sizing plan need to prove?
A database sizing plan must prove that retained data fits on disk and that peak reads, writes, cache misses, and connections stay inside measured node limits.
Step 1
Model
Define row growth, retention, compression, indexes, replicas, hot data, peak workload, provisioned nodes, and tested per-node capacity.
Step 2
Observe
Find the first storage or serving bottleneck, preserve explicit headroom, and separate measured limits from illustrative assumptions.
Step 3
Challenge
Start with the planned peak, then inject retention growth, new indexes, node loss, a hot partition, and compaction pressure.
Size the data and the path that serves it
Model retained bytes, indexes, replicas, memory, throughput, IOPS, and connections, then inject the failure your spreadsheet usually leaves out.
Scenario status
Headroom intact
Pressure test
Operational challenge
Challenges change the evaluated scenario, not the values you entered.
Sizing envelope
Planned peak
All nodes are available and traffic is evenly distributed.
3.44 TB
573 GB per surviving node
110 GB
100% covered by memory
4
6 survive this scenario
Read throughput
60% utilized
Storage allocation
See every byte added to the primary data
7.53 GB / day
Growth checkpoints
Retention fills the serving store
This assumes a steady ingest rate and immediate expiration after the retention window. Backups and archives are intentionally excluded.
Serving path
Trace workload from connections to disk
Cache hit rate is an illustrative estimate, not a benchmark.
Clients
21K QPS
1.2K concurrent
Surviving fleet
6 nodes
hottest gets 17%
Buffer cache
99% hit
384 GB available
Disk path
7.3K IOPS
9% utilized
Capacity lanes
One saturated lane can reject the design
Read throughput
60%
Write throughput
42%
Disk IOPS
9%
Connections
50%
Working-set memory
29%
Hottest node
60%
Headroom intact
Read throughput
Keep measured per-node limits, cache-hit rate, and connection-pool saturation aligned with this planning envelope.
- Rows retained
- 912.5M
- Raw primary data
- 1.1 TB
- Durable stored bytes
- 2.75 TB
- Effective index overhead
- 35%