Capacity Planning Best Practices
Capacity planning keeps PostgreSQL ahead of traffic, disk, and connection growth. Review quarterly with fresh pg_stat_statements and table size exports, not gut feel.
//
Search across all documentation pages
Capacity planning keeps PostgreSQL ahead of traffic, disk, and connection growth. Review quarterly with fresh pg_stat_statements and table size exports, not gut feel.
pg_total_relation_size.n_dead_tup not climbing unbounded.idx_scan = 0 over 30d reviewed.30-60 minutes with pre-read dashboard; action items assigned before end.
Platform SRE maintains; product supplies growth assumptions.
Smaller SKU OK; match major version and extension set; connection math still taught.
Disk > 90% or connections > 90% - immediate vertical change; postmortem updates forecast.
Right-size down in quiet quarter only with metrics proof, not finance-only mandate.
Neon compute autoscale still needs connection and storage forecasts.
Avoid for production OLTP capacity plans - use fixed performance class.
Store pgbench or k6 results per release on staging at fixed SKU.
Tag instances; chargeback storage growth to service cost center.
Tech lead acknowledges review in ticket; ADR if crossing shard threshold.
Stack versions: This page was written for PostgreSQL 18.4 (stable 18, maintenance 17), pgvector 0.8+, PgBouncer 1.x, Patroni 3.x, and PostGIS 3.5+.
Reviewed by Chris St. John·Last updated Jul 19, 2026