Summary
PostgreSQL's built-in streaming replication provides the replication substrate that makes the read replica pattern operational. Physical and logical replication are both supported, enabling read scaling without data modification.
Evidence
- ·PostgreSQL streaming replication documented since v9.0 (2010)
- ·Physical replication supports synchronous and asynchronous modes
- ·Hot standby allows read queries on replicas without blocking replication
- ·Logical replication (v10+) supports partial replication and cross-version setups
Operational Context
- ·Primary must have wal_level=replica (or logical for logical replication)
- ·Replica lag must be monitored via pg_stat_replication on primary
- ·Promote-to-primary procedure must be rehearsed as part of DR planning
Tradeoffs
- ·Synchronous replication eliminates lag but doubles write latency
- ·Asynchronous replication allows data loss equal to replication lag on primary failure
- ·Each replica consumes WAL sender processes on the primary
Generator Relevance
PostgreSQL + read_replica is the canonical first scaling recommendation. Architecture generator should surface this combination first for read-heavy PostgreSQL workloads.
Evidence grounding
Grounded, 4 supporting itemsCore PostgreSQL feature since version 9.0. Streaming replication is the production standard for PostgreSQL read scaling. Extremely well-documented.