Skip to main content

Replication

Synchronous Replication​

  • How it works:

    • A write operation is sent to the primary database.
    • The primary forwards the change to one or more replicas.
    • The primary waits until at least one (or all) replicas confirm they've persisted the change before acknowledging success back to the client.

  • Guarantees:

    ✅ Strong consistency: data on replicas is always up-to-date with the primary.

    ✅ If the primary crashes, a replica can take over with no/little data loss.

    ❌ Higher latency: write performance suffers because the client waits for replicas.

    ❌ More sensitive to network issues.

  • Use cases:

    • Banking, payments, inventory → consistency is critical.
    • Systems where data loss cannot be tolerated.

Asynchronous Replication​

  • How it works:

    • A write operation is committed only on the primary.
    • The primary acknowledges success immediately to the client.
    • Replicas receive updates later (in the background).

  • Guarantees:

    ✅ Low latency writes: faster for clients.

    ✅ Scales better across regions (WAN replication).

    ❌ Eventual consistency: replicas may temporarily lag behind.

    ❌ If the primary crashes, recent transactions may be lost (not yet replicated).

  • Use cases:

    • Analytics, reporting, caching layers.
    • Geo-distributed systems where speed is more important than absolute consistency.
    • Social media (likes, views counters can tolerate slight lag).

Semi-Synchronous (Hybrid)​

  • Primary waits for at least one replica to confirm, but not necessarily all.
  • Reduces risk of data loss while limiting latency impact.

Visual Summary​

Synchronous:
Client -> Primary -> Replica -> ACK -> Client

Asynchronous:
Client -> Primary -> ACK -> Client -> Replica (later)

Best practice​

  • Use synchronous for critical, transactional data.
  • Use asynchronous for read scaling, analytics, global distribution.
  • Many production systems use a mix:
    • Primary + synchronous replicas (local, for durability).
    • Asynchronous replicas (remote, for geo-read scaling).

PostgreSQL implementation​

Postgres replicates WAL (Write-Ahead Log) records from a primary to one or more standbys. Standbys can be:

  • Physical (streaming) replicas — byte-for-byte copies of the cluster (same major version).
  • Logical replicas — row-level change streams to different schemas/versions (publications/subscriptions).

Reads on standbys are possible with hot standby; writes always go to the primary.