Streaming Replication Best Practices
One synchronous partner max unless you understand latency. These rules keep physical replication reliable under failover and load spikes.
Search across all documentation pages
One synchronous partner max unless you understand latency. These rules keep physical replication reliable under failover and load spikes.
max_slot_wal_keep_size as a disk safety valve. Complement, not replace, slot hygiene.application_name to synchronous_standby_names. Misnamed standbys never join quorum.synchronous_commit = off. Scope durability downgrades to batch roles only.remote_write over remote_apply unless apps read from standby post-commit. Lower commit latency.pg_stat_replication byte lag, not only time lag. Idle workloads hide delay in LSN gap.scram-sha-256 for replication users in pg_hba.conf. No plaintext passwords in conf files.sslmode=verify-full in primary_conninfo). Encrypt cross-AZ and cross-region links.REPLICATION login only, no superuser.pg_basebackup after wal_status = lost. Incremental catch-up cannot fix missing WAL.Async standby, physical slot, TLS, byte lag alert, documented promotion runbook.
Only with measured commit latency impact and Patroni policy for quorum loss.
Flat for HA failover nodes; cascading when primary max_wal_senders or cross-region cost is the bottleneck.
Logical and physical slots share WAL retention risk. Monitor all slots together.
Replication is not backup. Keep pg_dump or pgBackRest alongside standbys. See Backup Basics.
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