CONCEPT Cited by 1 source
wal_level=logical¶
Definition¶
wal_level=logical is the Postgres configuration setting
that instructs the primary to include enough information in
the WAL to
support logical decoding — the reconstruction of per-row
change events (insert/update/delete with column values) from
the underlying physical-redo log. It is the highest of three
valid values (minimal → replica → logical); each level is
a strict superset of the one below it.
Only under wal_level=logical can
logical replication
slots be created; only under logical decoding can Postgres's
built-in logical replication,
Debezium's Postgres connector,
and similar CDC tooling operate.
The load-bearing architectural asymmetry¶
Sam Lambert canonicalises the mechanism-level asymmetry that causes Postgres's HA-CDC coupling:
"The WAL is a physical redo log for crash recovery and physical standby replication. The fact that a downstream consumer needs certain WAL retained is tracked in a primary- local catalog state inside
pg_replication_slots. That state advancement only occurs when the consumer connects and acknowledges data. Historically, this state never rode along in WAL, so standbys had no authoritative copy." (Source: sources/2026-04-21-planetscale-postgres-high-availability-with-cdc)
The asymmetry: the replication stream (WAL) and the
replication-progress metadata (slot catalog) live in different
substrates. wal_level=logical makes logical decoding
possible by enriching the WAL, but it does not push slot
progress into the WAL — slots remain primary-local catalog
objects. Postgres 17 failover
slots partially bridge this gap by serialising slot metadata
into WAL so standbys can mirror it.
Operational cost¶
wal_level=logical adds two costs vs wal_level=replica:
- More data in the WAL — row images of updated columns
(
REPLICA IDENTITYconfigurable) and additional catalog metadata. Measured overhead varies by workload but is typically 10-30% more WAL volume. - Logical decoding work on the primary — the pgoutput (or custom plugin) decoder runs in the walsender process for every active slot, CPU-proportional to change volume.
Seen in¶
- sources/2026-04-21-planetscale-postgres-high-availability-with-cdc
— canonical wiki disclosure of the primary-local-catalog
vs WAL-stream asymmetry that
wal_level=logicalcreates. Sam Lambert (PlanetScale CEO, 2025-09-12) names the WAL as a "physical redo log" and the slot state as living "in a primary-local catalog" — the two-substrate structure is the architectural root of the HA-CDC coupling.