Overview

This page is the atomic definition. Postgres replication setup lives at postgres.

Definition

A read replica is a secondary database instance that streams committed changes from the primary via the write-ahead-log and serves read-only queries. Writes always go to the primary; reads can go to any replica. The replica lags behind the primary by some replication delay (typically milliseconds to seconds), so queries against it may return stale data, making it a base-like system for those reads. Postgres supports physical streaming replication (byte-level WAL copy) and logical replication (row-level change streams). Cloud platforms (RDS, Neon, Supabase) provision replicas with one click. Common use cases: reporting and analytics that would otherwise contend with OLTP writes; read-heavy API workloads where stale reads are acceptable; geographic distribution of read traffic. Direct your writes and reads that require up-to-date state exclusively to the primary.

When it applies

Add a read replica when primary CPU is dominated by read queries and write latency is suffering. Do not route writes or read-your-own-writes queries to a replica unless the application handles replication lag explicitly.

Example

An e-commerce site routes product catalog searches to a read replica (stale by 200 ms is acceptable) and routes checkout queries to the primary (inventory must be current).

  • postgres - Postgres streaming replication and WAL-based architecture.
  • write-ahead-log - the mechanism that replicates changes to replicas.
  • base - the consistency model replicas exhibit due to replication lag.
  • materialized-view - materialized views provide another form of precomputed read offloading.

Citing this term

See Read replica (llmbestpractices.com/glossary/read-replica).