PostgreSQL Replication and High Availability

August 11, 2026 Khimananda Oli 8 min read Database

By Khimananda Oli | Last reviewed: August 2026

Databases are the single most critical failure point in modern infrastructure, and relying on a standalone instance is a risk no production system should accept. Implementing PostgreSQL replication and high availability ensures your data survives hardware failures, network partitions, and maintenance windows without manual intervention. This guide covers the practical architecture, configuration, and tooling required to build a resilient cluster that meets SOC 2 and ISO 27001 compliance standards.

Quick answer: PostgreSQL replication and high availability combine native streaming replication for synchronous or asynchronous data redundancy with an external orchestrator like Patroni and etcd to automate leader election and failover. This stack eliminates single points of failure, ensuring sub-minute recovery times and continuous read scalability for production workloads.

How does PostgreSQL replication and high availability architecture work?

At its core, PostgreSQL replication and high availability rely on separating the write path from the read path while maintaining data consistency across nodes. The primary server accepts all writes and streams Write-Ahead Log (WAL) records to one or more standby servers. These standbys continuously replay the WAL stream to maintain an identical copy of the dataset. In a high-availability setup, this replication layer is wrapped by a consensus-based orchestrator that monitors node health and manages virtual IP addresses or DNS endpoints.

For teams managing infrastructure in Nepal or regions with variable network latency, understanding the distinction between synchronous and asynchronous replication is vital. Synchronous replication guarantees zero data loss (RPO=0) because the primary waits for at least one standby to confirm receipt before committing a transaction. Asynchronous replication offers lower latency but risks losing uncommitted transactions during a catastrophic primary failure. Most production environments use a hybrid approach: synchronous commit to a local standby for durability, and asynchronous replication to a remote region for disaster recovery.

Core PostgreSQL replication and high availability topology with Patroni orchestration and etcd consensus

This architecture removes ambiguity during failures. Without an orchestrator, administrators must manually promote a replica, risking split-brain scenarios where two primaries accept conflicting writes. Tools like Patroni integrate directly with etcd or Consul to lease leadership tokens, ensuring only one node can ever be promoted at a time. For teams exploring infrastructure as code with Terraform, defining these clusters declaratively prevents configuration drift and simplifies audit trails.

How do you configure streaming replication in PostgreSQL 17?

Native streaming replication is the foundation of any HA cluster. Before adding orchestration, you must correctly configure the database engine itself. PostgreSQL 17 continues to refine performance and monitoring for replication slots, making it the current stable choice for 2026 deployments.

Step 1: Configure the Primary Server

Edit postgresql.conf on the primary node to enable WAL archiving and replication connections. These settings balance durability with network overhead.

# postgresql.conf - Primary Node
listen_addresses = '*'
max_wal_senders = 10
wal_level = replica
wal_keep_size = 1GB
max_replication_slots = 5
synchronous_commit = on
synchronous_standby_names = 'ANY 1 (standby1, standby2)'
archive_mode = on
archive_command = 'test ! -f /mnt/wal_archive/%f && cp %p /mnt/wal_archive/%f'

Step 2: Configure Authentication and Access

Replication traffic must be secured. Never allow open replication access. Update pg_hba.conf to restrict connections to specific subnet ranges used by your standby nodes.

# pg_hba.conf
# TYPE  DATABASE        USER            ADDRESS                 METHOD
host    replication     replicator      10.0.1.0/24             scram-sha-256
host    replication     replicator      10.0.2.0/24             scram-sha-256

Step 3: Initialize Standby Replicas

Use pg_basebackup to create a consistent baseline copy of the primary. This command handles checksum verification and tablespace mapping automatically.

pg_basebackup -h primary-db.internal -D /var/lib/postgresql/17/main \
  -U replicator -P -X stream -R -S slot_standby1

The -R flag creates a standby.signal file and appends connection info to postgresql.auto.conf, eliminating manual standby configuration. The -S flag creates a physical replication slot, preventing the primary from removing WAL segments needed by this specific standby even if it falls behind temporarily.

When should you choose Patroni over manual failover?

Manual failover scripts are fragile. They cannot reliably distinguish between a crashed primary and a network partition, leading to data corruption or extended downtime. You should adopt Patroni when your RTO target is under 60 seconds or when operating across multiple availability zones.

Automatic Leader Election: Patroni uses distributed consensus to elect a new primary within seconds of detecting a failure, verified against etcd leases.
Replication Slot Management: Orphaned slots cause disk exhaustion. Patroni automatically creates and drops slots based on cluster membership.
Integration with Load Balancers: Patroni exposes REST APIs that HAProxy or Nginx can query to route traffic only to healthy nodes.
Safe Switchover: Planned maintenance becomes trivial with patronictl switchover, which gracefully demotes the current leader before promotion.

If you are running stateful workloads on Kubernetes, consider reading about Kubernetes basics first, as Patroni integrates deeply with K8s primitives via the Postgres Operator (PGO). However, for bare-metal or VM-based deployments common in Nepali fintech and government projects, the etcd-based Patroni setup remains the gold standard for compliance-ready infrastructure.

Failover timeline showing detection, consensus voting, and promotion in PostgreSQL replication and high availability clusters

What are the trade-offs between synchronous and asynchronous replication?

Choosing the right replication mode is a business decision disguised as a technical configuration. There is no universally correct setting; the optimal choice depends on your data loss tolerance versus latency requirements.

Criteria	Asynchronous Replication	Synchronous Replication
Data Loss Risk (RPO)	Potential loss of unreplicated WAL on crash	Zero data loss (guaranteed commit)
Write Latency	Low (primary doesn't wait)	Higher (waits for standby ACK + network RTT)
Availability Impact	Primary continues if standby fails	Primary blocks if all sync standbys fail
Best Use Case	Analytics replicas, cross-region DR	Financial transactions, compliance-critical data
Network Sensitivity	Tolerant of jitter/packet loss	Degrades severely with unstable links

In practice, I recommend configuring synchronous_standby_names = 'ANY 1 (local_standby)' for domestic deployments where latency is predictable. For cross-border setups involving Nepal and international cloud regions, keep the remote replica strictly asynchronous to prevent transcontinental network issues from stalling your primary database. Always monitor replication lag using pg_stat_replication; alerts should trigger well before lag exceeds your acceptable RPO window.

How do you monitor and validate replication health?

Configuration alone does not guarantee safety. Continuous validation is mandatory for audit readiness. A silent replication failure is worse than an obvious outage because it creates false confidence during normal operations.

Check Replication Lag: Query pg_stat_replication on the primary. Compare sent_lsn vs replay_lsn. A growing gap indicates network saturation or replay bottlenecks on the standby.
Verify Slot Activity: Unused replication slots retain WAL indefinitely, filling disks. Run SELECT * FROM pg_replication_slots WHERE active = false; regularly.
Test Failover Quarterly: Automated tests beat runbooks. Schedule controlled switchovers during low-traffic windows to verify that Patroni, load balancers, and application connection pools behave correctly.
Monitor etcd Health: If etcd loses quorum, Patroni cannot perform failovers. Track etcd leader elections, disk fsync duration, and member connectivity separately from Postgres metrics.

For teams integrating observability, explore monitoring with Prometheus and Grafana to visualize replication lag trends over time. Raw numbers in a terminal don't reveal gradual degradation; dashboards do. Ensure your alerting thresholds account for legitimate maintenance windows to avoid fatigue, but never suppress lag alerts entirely.

Visual comparison of synchronous vs asynchronous modes for PostgreSQL replication and high availability planning

Implementing Resilient PostgreSQL Replication and High Availability

Building a reliable cluster requires treating replication as a first-class infrastructure component, not an afterthought. Start with native streaming replication configured securely, layer Patroni for automated governance, and validate your assumptions through regular testing. Whether you're supporting a Kathmandu-based e-commerce platform or a global SaaS product, the principles remain identical: automate failover, monitor lag obsessively, and align your replication mode with actual business risk tolerance. If your current setup lacks automated failover or hasn't been tested in six months, it's already broken—you just haven't noticed yet. Reach out via my contact page if you need help auditing or architecting your database resilience strategy.

Frequently Asked Questions

Synchronous replication guarantees zero data loss by waiting for standby confirmation before committing, increasing latency. Asynchronous replication offers better performance but risks losing unreplicated transactions during primary failure. Choose based on your specific RPO requirements and acceptable write latency trade-offs for high availability.

Enable wal_level=replica, set max_wal_senders, and create a replication user. Configure primary_conninfo on the standby pointing to the primary host. Use pg_basebackup for initial sync. Ensure pg_hba.conf allows replication connections. Test failover procedures thoroughly before production deployment to validate your high availability setup.

No. Native streaming replication requires external tooling like Patroni, repmgr, or pg_auto_failover for automated promotion. These tools monitor cluster health and execute failover logic when the primary becomes unreachable, completing the high availability architecture beyond basic data redundancy.

Heavy write loads, insufficient network bandwidth, slow standby disk I/O, or long-running queries blocking WAL apply cause lag. Monitor pg_stat_replication.sent_lsn versus replay_lsn. Optimize with parallel apply workers, faster storage, or tuning wal_receiver_timeout to maintain consistent replication performance under load.

Yes. Streaming replicas handle read-only queries, offloading the primary. Route SELECT statements via connection poolers like PgBouncer or application-level logic. Be aware of replication lag causing stale reads. This pattern supports horizontal read scaling while maintaining a single writable primary for consistency.

Logical replication copies row-level changes using publication/subscription, allowing selective table replication across different PostgreSQL versions. Physical replication copies entire WAL blocks byte-for-byte, requiring identical major versions. Logical suits partial migrations; physical provides complete cluster redundancy for disaster recovery and high availability scenarios.

Track replication lag bytes and seconds via pg_stat_replication, WAL sender/receiver process counts, and standby replay location. Alert when lag exceeds defined thresholds or senders disconnect unexpectedly. Integrate with Prometheus postgres_exporter for dashboards showing real-time replication status across your high availability cluster nodes.

Risky. If that single standby fails, writes block indefinitely or timeout depending on synchronous_commit settings. Use synchronous_standby_names='ANY 1 (standby1, standby2)' with multiple standbys to ensure at least one acknowledges commits, balancing durability guarantees with continued availability during individual node failures.

Always encrypt replication traffic using SSL/TLS certificates. Restrict pg_hba.conf to specific standby IPs with scram-sha-256 authentication. Avoid password-based replication users. Consider VPN tunnels or private networking. Rotate credentials regularly and audit connection logs to prevent unauthorized access to your replication stream.

Replication slots retain WAL files until the standby consumes them, potentially filling disk if downtime extends too long. Set max_slot_wal_keep_size in PostgreSQL 17 to cap retention. Without this limit, unbounded WAL accumulation can crash the primary, defeating high availability objectives entirely.

Costs include three compute instances, shared or replicated storage, and load balancer fees. Cloud-managed options like AWS RDS Multi-AZ or Azure Flexible Server bundle these but cost 2-3x single-instance pricing. Self-hosted reduces licensing costs but increases operational overhead for maintenance and failover testing.

Yes. Use pg_basebackup with --checkpoint=fast to create a base backup while the primary continues serving traffic. Configure streaming replication on the new standby afterward. This online expansion capability is fundamental to PostgreSQL high availability operations without scheduled maintenance windows or service interruption.

Misconfigured priority settings, stale health checks, or split-brain scenarios cause incorrect promotions. Verify Patroni or repmgr priority weights match intended topology. Ensure fencing mechanisms prevent old primaries from rejoining as writable. Review failover logs to diagnose timing issues and refine election criteria for future incidents.

No. Replication propagates all changes including destructive mistakes instantly. Implement point-in-time recovery with continuous WAL archiving to restore pre-error states. Combine with delayed replicas or logical replication filters for additional protection layers within your broader data safety and high availability strategy.

Choose managed services when team expertise is limited, compliance permits cloud hosting, and budget allows premium pricing for reduced operational burden. Self-host when requiring custom extensions, strict data sovereignty, or cost optimization at scale where engineering resources justify infrastructure management complexity and responsibility.