What it is
The Capacity Planning Worksheet is a consultant-grade spreadsheet model that projects your database's storage, IOPS, and connection demand forward over 12, 24, and 36 months from today's footprint and growth rate — then tells you exactly when you will run out of headroom and what to provision. You enter your current size, monthly growth rate, and provisioned ceilings once, and the worksheet compounds the growth, computes remaining headroom against each ceiling, flags the month you cross the scale-up threshold, and produces a sizing recommendation you can hand to infrastructure. It replaces the surprise of a full disk with a date on the calendar.
As a workbook it is organized into five sheets: Instructions, Inputs, Storage Projection, IOPS & Connections, and Recommendation. The Inputs sheet takes today's measured values — current database size in GB, a monthly growth rate from a 3-6 month trailing average, the provisioned storage ceiling, and a scale-up threshold (80% is the common default). The Storage Projection sheet compounds that size forward, computes headroom percentage at each horizon, and fires a scale flag when projected usage reaches the threshold, with a threshold-size figure telling you the GB level at which to provision more.
The worksheet's insight is that storage is rarely the only ceiling. The IOPS & Connections sheet projects throughput and connection demand forward at the same growth rate — a reasonable proxy when load scales with data — and checks headroom against your provisioned limits, so a connection-pool ceiling does not blindside you while you are only watching disk. The Recommendation sheet then pulls the headline figures together — current utilization, projected size at 12 and 36 months, months of runway to the threshold — and combines your storage runway with your tightest current resource into a single, defensible provisioning call with a buffer baked in.
What it's used for
Teams use the capacity planning worksheet to turn database growth from a quiet liability into a planned, budgeted decision. It is a forecasting and justification tool. The concrete jobs it does:
- ✓ Projecting storage forward — compounding today's database size at the monthly growth rate over 12, 24, and 36 months so you can see the trajectory, not just the current number.
- ✓ Computing headroom against the provisioned ceiling at each horizon, expressed as the free share remaining, so you know how close to the wall you are at any point.
- ✓ Flagging the scale-up month — firing a clear signal when projected usage reaches your scale-up threshold (commonly 80%), and naming the GB level at which to provision more.
- ✓ Projecting IOPS and connection demand at the same growth rate and checking headroom against those ceilings, so throughput or pool exhaustion does not surprise you while you watch only storage.
- ✓ Producing months-of-runway figures — translating the projection into 'you have N months until you hit the threshold,' which is the number that drives the provisioning timeline.
- ✓ Generating a defensible sizing recommendation — combining the storage runway with the tightest current resource and adding a buffer (the worksheet uses +25% for a 36-month ceiling) for infrastructure to act on.
- ✓ Giving infrastructure and finance a single artifact to justify a provisioning spend, grounded in measured current values and a transparent growth assumption.
Who uses it
Capacity planning bridges operations, infrastructure, and budget, so the worksheet is written for the people who watch growth, provision capacity, and pay for it.
Context & good to know
Databases fail quietly. Storage fills, IOPS saturates, or the connection pool maxes out, and the first symptom is a production incident at the worst possible time. Capacity planning exists to replace that surprise with a date, and this worksheet's whole design — compound the current size at the observed growth rate, compare to the ceiling, report months of runway — is built to give the team that date early enough to act calmly rather than scramble. The shift is from reactive firefighting to a scheduled, budgeted provisioning decision.
The choice of growth rate is the model's most consequential input, which is why the worksheet is explicit about using a 3-6 month trailing average rather than a launch spike. Compounding magnifies the assumption: a 6% monthly growth rate roughly doubles the database in a year, so a too-high or too-low input drastically moves the scale-up date. Grounding the rate in recent measured trend keeps the projection honest, and revisiting it as the trend changes keeps the date accurate.
Storage gets the attention, but the worksheet's IOPS-and-connections sheet reflects a hard-won operational truth: the connection pool and throughput ceilings often bite first. A database can have plenty of disk and still fall over because sustained connection usage above 80% of max_connections risks pool exhaustion and hard refusals, or because IOPS saturates under load. Projecting all three ceilings together is what makes the recommendation reflect the tightest real constraint, not just the most visible one.
Spotsaas offers this worksheet in its database-management resources because capacity headroom is a real cost-and-risk dimension teams weigh when choosing and sizing a database. Whether a team runs PostgreSQL, MySQL, MongoDB, or a managed service like Amazon Aurora that auto-scales storage but still caps IOPS and connections, knowing the growth trajectory turns 'how big should we provision?' into a transparent, buffered number infrastructure and finance can both stand behind.