PostgreSQL CDC Source Configuration

Use this page when PostgreSQL is the source for a CDC workflow.

CDC mode reads changes from PostgreSQL WAL through logical replication. It is different from Load mode, which reads tables directly without WAL-based replication setup.

For the canonical setup flow, combine this page with:

• PostgreSQL Server Configuration
• What Is CDC?

When to use this page

Use this guide when you need:

• ongoing replication of inserts, updates, and deletes
• a PostgreSQL source that continues streaming changes after the initial load
• a CDC workflow instead of a bounded Load run

If you only need a one-time load or migration, use PostgreSQL Load Mode Guide instead.

Minimum source requirements

Before enabling CDC, confirm:

• the source runs PostgreSQL 14 or later
• the PostgreSQL connection already works in DBConvert Streams
• logical replication is enabled on the source
• replication capacity is sufficient for the environment
• the selected user has the required replication and read privileges

Required PostgreSQL settings

For a self-managed PostgreSQL source, the core settings typically include:

wal_level = logical
max_replication_slots = 5
max_wal_senders = 10

These values must fit your environment. The exact counts depend on how many replication consumers and slots the deployment uses.

Required privileges

The CDC user typically needs replication and login capability:

ALTER ROLE your_user WITH REPLICATION;
ALTER ROLE your_user WITH LOGIN;

It also needs read access to the tables the stream will capture.

Check CDC readiness

There are two places in the UI that surface CDC readiness:

Stream wizard — when creating a new stream, the Data Transfer Mode step checks the source automatically. If wal_level is replica, the Stream (Change Data Capture) option shows a warning ("PostgreSQL wal_level is 'replica' — must be 'logical' for CDC") and is disabled.

Connection page in Data Explorer — click the connection in the sidebar. The CDC readiness panel sits under Server Stats, because WAL settings and replication slots belong to the server, not to one database.

• The badge at the top answers whether CDC can run and whether anything needs attention.
• The line below it shows wal_level, used slots out of max_replication_slots, WAL senders and the WAL keep limit.
• The table lists every replication slot on the server.

If both places show CDC as ready, the source is configured. If not, apply the settings above and restart PostgreSQL.

Replication slots and disk space

A replication slot keeps every WAL file its consumer has not confirmed yet. WAL is shared by all databases on the server. A slot nobody reads keeps growing until the disk fills, and then the whole server stops.

Each stream gets its own slot named dbconvert_<stream config id>. Deleting the stream drops it. The Used by badge shows whose slot it is:

• Stream — a stream of this connection owns it. While the stream is stopped, its slot is inactive and keeps the changes it will resume from.
• Leftover — a DBConvert slot no stream owns, for example after its stream was deleted while the source was unreachable.
• Other tool — another replication consumer, such as Debezium.

WAL held turns yellow when an inactive slot holds more than 1 GB. Drop removes an inactive slot. A stream whose slot is dropped needs a full resync on its next start.

Set max_slot_wal_keep_size as a safety limit. A slot that exceeds it is invalidated instead of filling the disk, so the worst case becomes a CDC resync, not an outage. The panel warns when there is no limit and a slot is already holding a lot.

For a deeper look at how logical decoding works under the hood — replication slots, output plugins, and WAL consumer code — see PostgreSQL Change Data Capture with logical decoding.

Cloud-hosted PostgreSQL CDC sources

If the source is provider-managed, use the provider page for network and managed-service specifics, then return here for the DBConvert Streams CDC requirements:

• AWS Aurora PostgreSQL Guide
• Google Cloud SQL Connection Guide
• Azure Database Connection Guide
• Neon PostgreSQL Guide
• DigitalOcean Managed Database Guide
• YugabyteDB Guide

Generated columns

PostgreSQL does not send generated column values through CDC. A PostgreSQL target computes them itself. Any other target gets the table without them, and the migration plan says which columns are left out. See Generated column conversion.

Validation checklist

1. Test the PostgreSQL connection from the Data Explorer sidebar (right-click → Test connection) or from the connection editor.
2. Open the connection in Data Explorer and check the CDC readiness panel — it should show Ready for CDC.
3. Confirm the CDC user has REPLICATION and LOGIN roles and SELECT access to the target tables.
4. Start with a narrow CDC stream (one or two tables) before scaling to a larger scope.

Troubleshooting

Related docs

• PostgreSQL Server Configuration
• PostgreSQL Load Mode Guide
• What Is CDC?

Further reading

• PostgreSQL Change Data Capture with logical decoding