PostgreSQL consultant publishes deep dive on binary read replica internals

Database consultant Christophe Pettus released 'Binary read replicas in PostgreSQL, Part 1,' a detailed technical explainer covering the fundamentals of physical (binary) replication. The article clarifies that a replica is simply a server in permanent recovery that accepts queries, and traces how WAL (write-ahead log) mechanics determine replica behavior, capabilities, and limitations. It distinguishes binary replication from logical replication and catalogs what replicas cannot do: write operations, temporary tables, sequence advancement, certain locking modes, and more.

How WAL shapes replica behavior

• WAL records are physical byte-level changes, not logical SQL operations; this forces primary and replica to share the same PostgreSQL major version and hardware architecture
• A replica starts from a base backup (typically via pg_basebackup) and stays current by applying WAL in primary's order
• Two processes handle replication: walreceiver stores incoming WAL, startup process replays it to data files; these can be out of sync
• Streaming replication (direct connection) and archive-based replication (16MB segment files) can be used together; streaming typically keeps lag under one second
• Replication slots track per-replica progress but risk disk exhaustion if a replica disappears without max_slot_wal_keep_size configured
• Default settings wal_level=replica and hot_standby=on already enable replication in stock PostgreSQL installations

Why it matters

The article addresses a common operational gap: teams often deploy read replicas for scaling without fully understanding the permanent recovery model's implications, leading to application failures when supposedly read-only workloads attempt writes or temporary table creation.