A PostgreSQL replication slot makes the database keep write-ahead log files until the consumer confirms it has read them. If a Debezium connector captures a quiet table while the server is busy elsewhere, the connector may not confirm progress, and WAL can grow. Heartbeats and monitoring are the documented fixes.
What Debezium documents
The Debezium PostgreSQL connector docs have a section on WAL disk space consumption. They explain that disk used by WAL files can spike or grow out of proportion for several reasons, and show how to read the state of the slot: the confirmed_flush_lsn column in the pg_replication_slots view shows how far the connector has received data, and restart_lsn shows the oldest WAL the connector might still need.
If confirmed_flush_lsn keeps increasing while restart_lsn lags, the docs say the database needs to reclaim the space, which it typically does in batch blocks, and no action is needed.
Two cases that need action
- Many updates elsewhere, few in captured tables. Only a tiny share of changes relate to the captured tables, so the connector rarely has anything to confirm. The docs suggest periodic heartbeat events through the heartbeat.interval.ms property. For the connector to process heartbeat events from a table, that table must be in the publication named by publication.name.
- Several databases in one server. Slots work per database, but WAL is shared. If one database is high traffic and the captured one is low traffic, Debezium is not invoked and cannot confirm the position, so WAL grows until the captured database emits an event. The docs say to enable heartbeats and regularly emit change events, for example with a separate process that updates a table, or with heartbeat.action.query.
They also note that on Amazon RDS for PostgreSQL, an idle environment can show a similar pattern because RDS writes to its own system tables frequently, and that regularly emitting events solves it.
Why this is a security and resilience matter
A full database disk is an outage for every application on that server. A pipeline component that can cause that has a larger blast radius than its job suggests. Availability is part of security, and the control is operational rather than clever.
| Signal | Where to look | Action |
|---|---|---|
| WAL volume climbing | Server disk metrics | Alert before the disk fills |
| restart_lsn far behind | pg_replication_slots | Check connector health and heartbeats |
| Connector stopped | Connect worker status | Decide whether to resume or drop the slot |
| Unused slot | pg_replication_slots | Remove slots no connector uses |
A routine that works
- Alert on WAL disk use and on slot lag.
- Turn on heartbeats for low-traffic captures.
- Give every connector its own slot name and keep a list of who owns each.
- Remove slots when you retire a connector, since a slot with no consumer still holds WAL.
- Practise the recovery: what happens if the connector is down for a day?
Also review who can create slots, since an account with the replication privilege can create more of them. See what privileges a Debezium PostgreSQL connector needs.
Safeguard's asset discovery helps you keep a list of the services and components in your data platform. A free dependency scan is at gold.safeguard.sh/scan.
Quick check
Does growing WAL always mean something is wrong?
No. The docs say that when confirmed_flush_lsn advances and restart_lsn lags, the database reclaims space in batches, which is expected.
What does a heartbeat do here?
It makes the connector see regular events, so it can confirm its position and let the database reclaim WAL even when captured tables are quiet.
Sources
- Debezium connector for PostgreSQL, Debezium documentation, fetched 19 October 2026.
Last reviewed: 19 October 2026.
