Capacity Planning

Capacity planning answers two questions: what to provision now, and when the current provision runs out. Both need measurements, not rules of thumb.

Memory

Memory is the resource that changes performance discontinuously. While the working set fits in cache, reads are microseconds; when it stops fitting, they become storage round trips and latency rises by orders of magnitude.

Size memory from the working set, not the dataset — see Understanding Workload Types. Then add the engine's other consumers: per-connection buffers, sort and hash memory, and the operating system page cache the engine relies on.

Storage

Four components, all of which must be provisioned:

1. Current data, measured, not estimated from row counts.
2. Indexes, which are frequently 30–100% of table size and grow with every added index.
3. Operational overhead — WAL or binary logs, undo or MVCC versions, compaction or merge space. LSM engines can need substantial free space to compact at all.
4. Growth to the next provisioning event, plus the slack to survive an incident that produces an unusual amount of data.

IOPS and throughput

Measure the actual write amplification of your engine: one logical write becomes a WAL write, a data page write, index page writes, and later compaction or vacuum reads and writes. A factor of 5–20× is normal depending on engine and workload.

On cloud block storage, IOPS is provisioned separately from capacity and is frequently the real limit. Check whether your instance type has a throughput ceiling below the volume's — that mismatch is a common and invisible bottleneck.

CPU

Databases use CPU for query execution, but also for compression, checksums, TLS, replication apply and background maintenance. Two rules that hold in practice:

• Sustained utilisation above roughly 70% leaves no room for the unexpected — a plan change, a retry storm, or a rebuild. Queueing delay grows sharply as utilisation approaches saturation.
• Single-threaded bottlenecks matter more than total cores. Replication apply, checkpointing and some maintenance tasks are single-threaded in many engines; adding cores does not help them.

Connections

Connection capacity is usually the first hard limit an application hits, and it is a memory and scheduling limit rather than a network one. Size it as:

max_connections  >  sum(pool sizes of every application instance)
                  + replicas' replication connections
                  + monitoring and backup connections
                  + a reserved margin for administrative access

If that sum is large, the answer is a pooler, not a larger limit. See Connection Pooling.

Forecasting

Track each resource as a time series and extrapolate:

• Data volume and growth rate per month.
• Peak write throughput per week — peaks, not averages.
• Connection high-water mark.
• Working-set proxy: cache hit ratio over time.

The useful output is a date per resource: "connections saturate in 5 months, disk in 11, memory in 14". That converts capacity work from a reaction into a schedule. See Capacity Forecasting.