PostgreSQL Streaming vs Logical Replication
Fast recall
Quick revision
Core answer
synchronous_commit=remote_apply for zero data loss.Whether you can distinguish physical (WAL-level) from logical (row-level) replication, pick the right mode for HA vs migration vs CDC, and configure replication slots, synchronous commit, and publications correctly.
Using streaming replication for zero-downtime major-version upgrades — it cannot cross major versions. Another is forgetting to drop orphaned replication slots, which causes the primary's WAL to grow until disk fills.
Explain replication slots and why they are required for reliable standbys, how `pg_stat_replication` diagnoses lag, and how logical replication underpins Debezium-based CDC pipelines.
Interview-ready guide
Interview answer
PostgreSQL has two replication systems and choosing the right one is usually half the interview answer.
Streaming replication — for HA and read scaling
- Ships raw WAL bytes from the primary to standbys that replay them block-for-block; the standby is an identical copy and can serve read-only queries
- Configure
wal_level=replica, create a replication slot so the primary keeps WAL until the standby consumes it, and take a base backup withpg_basebackup -Rto bootstrap the standby - Monitor with
pg_stat_replication— the LSN diff betweensent_lsnandreplay_lsnis your lag metric
Logical replication — for upgrades and partial copies
- Decodes WAL into row-level change events and ships them per publication; subscribers apply through regular SQL, so cross-version and cross-database replication work
- Used for zero-downtime major-version upgrades, selective replication of a few tables, and CDC into Kafka via Debezium's
pgoutputplugin - Requires primary keys on replicated tables and manual DDL propagation — run Flyway on both sides
Pitfalls worth mentioning
- Orphaned replication slots fill
pg_waland bring down the primary — always drop slots when retiring standbys - Synchronous commit modes trade durability for write latency; pick based on how far the sync standby is geographically
In practice: streaming for HA, logical for anything that crosses a boundary — version, database, or system.
PostgreSQL Streaming vs Logical Replication
Direct Answer
PostgreSQL offers two replication families. Streaming (physical) replication ships WAL records from the primary to standbys byte-for-byte — the standby is an exact block-level copy, great for HA and read scaling but bound to the same major version and cluster-wide. Logical replication decodes WAL into logical row changes per publication and applies them on the subscriber, enabling cross-version upgrades, selective table replication, and cross-database data movement. Sync modes range from async (default) to synchronous_commit=remote_apply for zero data loss.
Common Mistakes & Pitfalls
Using streaming replication for zero-downtime major-version upgrades — it cannot cross major versions. Another is forgetting to drop orphaned replication slots, which causes the primary's WAL to grow until disk fills.
Check your understanding
Answer these without looking back at the article.
- What is a replication slot and why is it required for reliable standbys?
- How would you perform a major-version upgrade with near-zero downtime using logical replication?
- How does Debezium hook into PostgreSQL's WAL stream?
- What does `synchronous_commit = remote_apply` guarantee and what does it cost?
Related interview prep categories
2Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.