Debezium Connector Config Generator
Fill in your source database and get a complete Debezium connector configuration, with the settings that are easy to forget already included: snapshot mode, the replication slot and publication for PostgreSQL, the unique server id for MySQL, the internal schema history topic, the ExtractNewRecordState transform that flattens change events into plain rows, heartbeats that stop an idle slot from pinning WAL, and sensible retry behaviour. Export it as Kafka Connect JSON, as a ready-to-run curl command, or as Debezium Server application.properties. The source-side prerequisites — wal_level, binlog_format, CDC enablement, grants — are generated alongside. Everything runs in your browser; no credentials leave the page.
Do more than debezium connector config generator — meet Chat2DB
Chat2DB is an AI-powered SQL client for Windows, macOS and Linux. Write SQL in natural language, format and optimize queries automatically, and manage MySQL, PostgreSQL, Oracle and 20+ other databases in one workspace.
How to use
- Pick your source database and fill in the host, database, user and the topic prefix that will namespace every Kafka topic.
- List the tables to capture, choose a snapshot mode, and toggle the unwrap transform, heartbeats and Avro to match your pipeline.
- Copy the config into Kafka Connect (or Debezium Server), and run the generated source-side setup SQL first so logical decoding or CDC is actually enabled.
Frequently asked questions
What snapshot mode should I use in Debezium?
initial is the right default: Debezium takes a consistent snapshot of the selected tables, emits every existing row as a read event, then switches to streaming from the log. Use no_data (schema_only on Oracle) when the target already has the historical data and you only want changes from now on. never skips the snapshot entirely and starts from the current log position — you keep the schema but risk missing rows that changed while the connector was down. when_needed re-snapshots automatically if the stored offset is no longer valid, which is convenient but can quietly re-emit an entire table. For re-snapshotting one table later without restarting, enable the signalling table and use an incremental snapshot instead.
Why does my PostgreSQL disk fill up after adding Debezium?
A logical replication slot holds every WAL segment from its restart_lsn onward until the consumer confirms it. If the connector is stopped, failing, or simply watching a low-traffic database, the slot never advances and WAL accumulates until the volume is full. Two defences: monitor pg_replication_slots for retained WAL, and enable heartbeats so the connector periodically writes a marker and flushes its offset even when no captured table has changed. Both are generated above. Also drop slots left behind by connectors you have deleted — removing the connector does not remove the slot.
What does the ExtractNewRecordState transform do?
By default a Debezium event is an envelope containing before, after, source metadata and an op code. That is precise but awkward for most sinks, which expect the row itself. ExtractNewRecordState (the unwrap transform) flattens the envelope down to the after state, so a change event looks like an ordinary record. With delete.handling.mode set to rewrite, deletes arrive as a row carrying a __deleted flag rather than vanishing, and add.fields keeps the operation type and source timestamp as prefixed columns. To inspect the source tables and the resulting rows side by side, connect with Chat2DB at https://chat2db.ai/download or https://app.chat2db.ai.
