Replication & High Availability

Replication means keeping a copy of your database, kept continuously up to date, on one or more additional servers. It matters for a few distinct reasons: redundancy (a copy survives if the primary server fails), read scaling (spread read-heavy traffic across multiple servers), and disaster recovery (a geographically separate copy protects against a whole-datacenter failure).

Streaming Replication

PostgreSQL's built-in replication mechanism is streaming replication. Every change to the database is first recorded in the Write-Ahead Log (WAL) — a durable, sequential log of every modification, which PostgreSQL uses for crash recovery even on a single standalone server. In a replicated setup, the primary server continuously streams this WAL to one or more standby (replica) servers, which replay it to stay in sync with the primary in near-real time.

Synchronous vs Asynchronous Replication

Mode	How It Works	Trade-off
Asynchronous (default)	The primary commits a transaction and returns success to the client immediately, without waiting for any standby to confirm it received the change.	Best performance/latency, but a small window of data loss is possible if the primary fails before a standby catches up.
Synchronous	The primary waits for at least one designated standby to confirm it has received (and optionally applied) the WAL before the transaction is reported as committed.	Stronger durability guarantee — no committed transaction is lost even if the primary fails — at the cost of added commit latency.

Read Replicas

A standby server can also accept read-only queries while it replays WAL from the primary (this is called a "hot standby"). Applications route read-heavy traffic — reports, dashboards, search — to one or more read replicas, keeping that load off the primary so it can focus on handling writes.

basic-standby-setup.sh

Bash

# On the standby: take a physical base backup from the primary
pg_basebackup -h primary-host -D /var/lib/postgresql/data -U replication -P -R

# -R writes a minimal standby configuration automatically,
# pointing this server at the primary to begin streaming WAL.

Failover

If the primary server fails, one of the standbys can be promoted to become the new primary, and applications are redirected to it. PostgreSQL provides the mechanism to promote a standby (pg_ctl promote or SELECT pg_promote();), but deciding when to fail over, which standby to promote, and automatically re-pointing application traffic is not something built-in streaming replication handles by itself.

Detecting that the primary has actually failed (vs. a transient network blip) reliably is hard, and false failovers cause more problems than they solve.
Automated failover needs cluster-management logic on top of PostgreSQL's replication primitives.

Automated HA typically needs extra tooling

Robust, automated high availability in production almost always involves additional tooling layered on top of PostgreSQL's built-in replication — projects like Patroni or repmgr handle leader election, health checking, and automated failover/promotion. This page introduces the underlying replication concepts; it is not a complete high-availability runbook, and a real production HA setup is a meaningful project in its own right.