# PostgreSQL consultant publishes deep dive on binary read replica internals

> **Key takeaway:** Christophe Pettus published the first part of a technical series explaining how PostgreSQL binary read replicas work, why they behave unexpectedly, and what they can and cannot do.

**Published:** 2026-10-20T16:00:00+00:00 
**Source:** Planet PostgreSQL 
**Category:** databases-storage 
**Canonical URL:** https://fosswire.org/news/postgresql-consultant-publishes-deep-dive-on-binary-read-rep.html 

## Summary
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.