Worlber
PostgreSQL

PostgreSQL Production Readiness: A Practical Go-Live Checklist

Date Published

Production starts with explicit objectives

A database is not production-ready because it accepts connections. Define recovery point objective, recovery time objective, expected peak connections, growth rate, maintenance windows, and ownership before go-live. These decisions determine the architecture. A system that may lose five minutes of data needs a different backup and replication design from one that may lose none.

Build a boring, repeatable foundation

Pin a supported PostgreSQL major version, document the package source, separate database data from operating-system files, enable data checksums at initialization, and synchronize time on every node. Keep configuration in version control or configuration management. Avoid unexplained tuning copied from another environment; every non-default setting should have an owner and a reason.

Protect access before tuning performance

Listen only on required interfaces, use host-based authentication rules that name exact networks, require SCRAM-SHA-256, and use TLS for traffic that crosses a trust boundary. Applications should have dedicated login roles and should not own schemas. Human administration should use named accounts with auditable elevation instead of shared superuser credentials.

Make failure visible

Collect database availability, connection utilization, transaction rate, replication lag, WAL generation, checkpoint duration, cache hit ratio, lock waits, deadlocks, table growth, and backup status. Enable pg_stat_statements with an agreed retention and privacy policy. Alert on symptoms that need action, not on every harmless fluctuation.

Prove recovery

A green backup job is not evidence of recoverability. Restore the latest base backup into an isolated environment, replay WAL to a chosen point in time, run application-level checks, and record the actual recovery duration. Repeat after major upgrades and backup-tool changes. Production readiness is the ability to recover predictably, not merely the ability to start PostgreSQL.