PostgreSQL Streaming Replication on Dedicated Servers

PostgreSQL streaming replication copies write-ahead log (WAL) records from a primary database server to one or more standby servers as transactions are written. It can support read scaling, reporting, maintenance windows, and faster recovery without changing the application’s data model.

On dedicated servers, the team controls CPU, memory, storage, network paths, and operating-system settings. That control helps make replication predictable, but it does not remove the need to design for WAL retention, replication lag, failover, backups and recovery testing. This guide explains the main planning decisions before production deployment.

How PostgreSQL streaming replication works

The primary writes each committed change to WAL. A standby connects through a replication user, receives WAL records from a WAL sender, writes them locally, and replays them. The standby can remain read-only while it catches up.

PostgreSQL streaming replication is a database-level design, while the hosting layer determines how reliably the nodes communicate. Dataplugs’ Hosting Infrastructure for Real Time Collaboration Platforms discusses state consistency, backup design, replication and failover as infrastructure concerns.

• Primary and standby roles are explicit and should be documented
• WAL sender, WAL receiver and replay processes move changes through the pipeline
• Asynchronous replication acknowledges writes before a standby replays them
• Synchronous replication waits for one or more standbys before confirming a commit
• Physical replication copies a cluster; logical replication selects changes by database objects

Synchronous and asynchronous replication choices

Asynchronous replication usually keeps write latency lower because the primary does not wait for a standby. The trade-off is that a failure can leave the newest transactions unavailable on the standby. Synchronous replication can reduce that exposure, but every commit depends on the configured standby and network path.

The right mode follows the recovery point objective (RPO), recovery time objective (RTO), and distance between servers. Dataplugs’ Top Backup & Disaster Recovery Tips for Dedicated Hosting also emphasizes that replication, backups and failover procedures solve different recovery problems.

• Use asynchronous replicas when write latency and read scaling are priorities
• Use synchronous replication when losing acknowledged transactions is unacceptable
• Use quorum settings when more than one standby participates in commit confirmation
• Measure round-trip latency before placing synchronous nodes in different locations
• Keep an independent backup and point-in-time recovery path

Sizing dedicated servers for PostgreSQL replicas

Size the primary and standby for the write rate, data set, query mix, checkpoint activity and recovery target rather than connection count alone. A standby that is large enough for normal reads may still be too slow to replay a burst of WAL during peak writes.

Storage latency often becomes visible first in WAL flushes, checkpoints and replay. Dataplugs’ Optimizing Resource Allocation for Seasonal Website Traffic Spikes describes using measured CPU, memory, storage and bandwidth demand to plan dedicated infrastructure instead of sizing from averages.

• CPU headroom for queries, WAL compression, vacuum and replay
• RAM for shared_buffers, work_mem, connection pools and the filesystem cache
• Low-latency NVMe storage for data files, WAL and temporary workloads
• Network throughput for WAL volume, read traffic, backups and rebuilds
• Capacity margin for failover, reindexing, vacuum and replica catch-up

Tip: Test failover and replica rebuilds using the largest realistic data set and WAL burst. Average utilisation can hide a recovery bottleneck.

WAL retention, replication slots and lag

WAL must remain available until each standby has received what it needs. Settings such as wal_keep_size, replication slots and WAL archiving address different parts of that requirement. A slot protects WAL for a disconnected consumer, but an abandoned slot can allow pg_wal to consume the disk.

• Monitor both the amount of lag and its cause. pg_stat_replication shows sender and receiver progress on the primary, while standby views show receiver status and replay position. Alerts should cover lag time, lag bytes, slot growth and disk headroom.
• Set retention for the longest expected outage or maintenance window
• Limit or remove unused replication slots after checking their consumers
• Track sent, write, flush and replay LSN positions
• Alert before WAL or data volumes approach capacity limits
• Record the lag threshold that triggers traffic or failover decisions

Failover, promotion and application routing

Streaming replication moves data, but it does not by itself decide when a standby should become primary. Promotion needs an operator or an orchestration tool, a way to fence the old primary, and a controlled method for moving application traffic.

A dedicated-server design should test the full path: detect the failure, promote the correct node, update the write endpoint, recycle connection pools, and verify that no split-brain writer remains. Keep failback and replica rebuild steps in the same runbook.

• Define who or what has authority to promote a standby
• Fence or isolate the old primary before allowing a new writer
• Use a stable application endpoint, proxy or controlled DNS change
• Reconnect clients with backoff instead of creating a connection storm
• Document failback, timeline history and post-incident verification

Backups and point-in-time recovery

A replica is not a backup. Accidental deletes, bad migrations and corrupted writes can be replicated to every standby. Use base backups plus continuous WAL archiving so the team can restore to a known point before the incident.

Store recovery copies outside the primary server and test restores on separate capacity. The recovery plan should state retention, encryption, access control, restore order and the time required to rebuild a standby after a hardware or software failure.

• Schedule and verify base backups
• Archive WAL continuously and monitor archive failures
• Keep off-server or cross-site copies with protected access
• Use point-in-time recovery for operator or application mistakes
• Run restore and recovery drills against the stated RPO and RTO

Conclusion

Streaming replication on dedicated servers can provide a clear primary-standby model, predictable resource allocation and a practical foundation for read scaling and recovery. The design is reliable only when RPO/RTO, WAL retention, failover authority, backups, security and monitoring are defined together.

For workloads that need predictable single-tenant capacity for PostgreSQL and its supporting services, Dataplugs provides dedicated server solutions with configurable CPU, memory, storage and network options.

For more information, visit Dataplugs or contact sales@dataplugs.com.