Databases
Database Replication Slot Cleanup: Retire Slots After Consumers Move
Replication slots are easy to leave behind because they are usually created for something urgent: a migration, a change-data-capture connector, a search index rebuild, a warehouse feed, or a recovery test. Once the consumer moves, the slot may keep retaining WAL or equivalent change history even though no one is reading it. The cost is not always obvious until storage grows, backups slow down, or the database team has to explain why old change logs are still being preserved.
Cleanup should answer one question: is this slot still protecting an active consumer or recovery path? If not, retire it through evidence and owner approval instead of guessing from age.
Identify the consumer before judging the slot
Do not start with “inactive” as the only signal. A slot can be quiet because the consumer runs in batches, because a connector is paused during an incident, or because a migration is waiting for a final cutover. Build a small inventory that names the slot, database, plugin or mode, last confirmed consumer, lag, and ticket or runbook that created it.
| Slot clue | Evidence to collect | Cleanup interpretation |
|---|---|---|
| Slot name matches an old connector | Check deployment manifests, connector configs, and warehouse ingestion jobs | Candidate only if the replacement stream is live |
| Lag keeps growing | Compare retained bytes with consumer health and incident notes | Could be stale, or a broken active pipeline |
| No active process | Review batch schedules and maintenance windows | Silence is not proof for monthly or paused jobs |
| Created for migration | Confirm cutover date and rollback window | Retire after rollback evidence expires |
| No owner | Escalate to database and data platform owners | Ownership gap, not automatic deletion |
A focused SQL check can start the conversation:
SELECT slot_name, plugin, slot_type, active, restart_lsn, confirmed_flush_lsn
FROM pg_replication_slots
ORDER BY active, slot_name;The result lists candidates and position metadata. It does not tell you which business process depends on the slot.
Do not rush these cases
Slow down when the slot feeds audit trails, customer exports, fraud review, search indexing, or data warehouse ingestion. Those consumers may have lower traffic than the product database but higher recovery cost when data is missed.
Also slow down when a migration recently completed. Teams often keep a slot through a rollback window. If the rollback plan still says “replay from the old stream,” cleanup needs a plan change before the slot disappears.
Retire in stages
First, link each slot to a consumer or mark it as unknown. Second, confirm the replacement path has processed current changes and can catch up after a pause. Third, ask the owning team to choose keep, pause with expiry, or retire. Fourth, record the final position or backup reference if the slot was part of a migration audit trail.
The safest first action is often not removal. It may be adding monitoring for retained bytes, lowering an alert threshold, or setting an owner-visible expiry date on the migration work item.
Prevent stale slots
Require every new replication slot request to include the consumer name, owning team, expected lifetime, maximum acceptable lag, and cleanup condition. For migration-created slots, make slot retirement part of the cutover checklist. For permanent CDC streams, make the slot visible in the same operational dashboard as the connector that consumes it.
Key takeaways
- Replication slot cleanup protects storage, backup health, and data pipeline clarity.
- Inactive slots still need consumer and rollback review.
- Growing lag may indicate either waste or a broken critical feed.
- New slots should be created with owner, lifetime, and retirement conditions attached.