Section 3 of 3 · 7 minutes
Plan capacity from measured trends
Your goal
What you will be able to do
Estimate when storage, connections, or workload demand will reach an operating limit.
Why this matters at work
The practical reason
Capacity work is safer and cheaper when it happens before an incident window.
Learn
The idea in plain English
Record growth over comparable periods and keep the workload context. Database size can grow because of healthy business data, retained WAL, temporary work, or bloat; each needs a different response.
Use a conservative forecast and include the time needed to test and deploy the remedy. Escalate when the remaining window is shorter than the safe change lead time.
Remember these points
- Separate useful data growth from avoidable storage growth.
- Forecast with comparable observation periods.
- Include testing and rollout lead time in the threshold.
See it in SQL
Measure database size
Record a repeatable size point for the current database.
SELECT
current_database() AS database_name,
pg_database_size(current_database()) AS database_bytes,
pg_size_pretty(pg_database_size(current_database())) AS readable_size,
clock_timestamp() AS measured_at;Store the byte value for calculations and the readable value for reports. The timestamp makes later growth calculations possible.
Database size does not include every host filesystem consumer, so combine it with WAL, logs, backups, and temporary-space evidence when relevant.
A timestamped byte and readable size measurement for the current database.
Useful words
Important terms
- Capacity lead time
- The time required to approve, test, and safely add capacity or reduce demand.
Quick check · Not graded
Check your understanding
When should a capacity risk be escalated?
Your progress is saved to your signed-in account.