Debezium and Kafka Connect are not alternatives. Kafka Connect is Apache Kafka’s framework for running data-integration connectors, and Debezium is a family of change data capture source connectors that run inside that framework. The real decision is between Debezium’s log-based CDC and a query-based JDBC source connector, or between running Debezium on Connect and running Debezium Server standalone. Where Connect itself sits in the platform is covered in the complete Kafka guide.
The comparison framing undersells how settled this question is in practice. Shopify rebuilt its change data capture system on Kafka Connect and Debezium together in 2021, which is the normal shape: Debezium is the CDC engine, Connect is the runtime it usually runs in. When teams get stuck on “versus”, they are almost always really choosing between log-based CDC and something else, not between these two projects.
At a glance
Debezium, log-based CDC and JDBC source connector are scored here on the same four criteria, 40 points in all: Debezium, log-based CDC 31 out of 40, JDBC source connector 18 out of 40. Debezium, log-based CDC takes its best score on Complete change capture (10 out of 10) and its lowest on Setup and privileges (4 out of 10). JDBC source connector takes its best score on Setup and privileges (9 out of 10) and its lowest on Complete change capture (2 out of 10).
How the two fit together
Kafka Connect provides the runtime: workers, task distribution, offset tracking, converters and error handling. Debezium provides connector implementations for specific databases that plug into that runtime. A Debezium deployment on Connect is administered exactly like any other connector: submitted over the REST API, monitored through worker metrics, scaled through tasks.
Debezium’s connector family covers the mainstream relational and document databases, including PostgreSQL, MySQL, MariaDB, MongoDB, SQL Server, Oracle, Db2 and Cassandra (Debezium connector documentation).
Log-based CDC versus query-based JDBC
The comparison people actually run is Debezium against a JDBC source connector, because both move relational data into Kafka. The complete guide to Kafka change data capture covers the full landscape. The short version of the decision:
A Debezium connector's status and task detail, and the change events landing in a topic.
Where the requirement is complete change capture, low latency and minimal impact on the source database, log-based CDC is the standard answer. Where the requirement is a periodic copy of slowly changing reference data, polling is often enough.
The two approaches are marked out of 10 on four criteria, 40 points in all, with no criterion weighted above another. Complete change capture asks whether every change reaches Kafka, deletes and intermediate states included. Latency asks how soon a change arrives. Load on the source asks what capture costs the database itself. Setup and privileges asks what has to be granted and configured on the database before the first record flows.
The strongest argument for log-based CDC over query-based polling is a failure you cannot see. In the published analysis of a global sportswear retailer’s Kafka platform, a race condition in the query-based JDBC source connector caused silent data loss: concurrent database transactions overlapped the connector’s query window and records were skipped with no error raised. The immediate fix was tuning timestamp.delay.interval.ms to buffer until pending transactions complete, and the durable fix documented by their engineer was moving the affected paths to log-based capture. Polling can only ever sample the table. The log is the record of what actually happened.
Debezium, log-based CDC
debezium.io
31 out of 40 Total
- Reads
- The database change log: WAL, binlog, redo log
- Runs on
- Kafka Connect, or Debezium Server
- Complete change capture
- 10 out of 10
- Latency
- 8 out of 10
- Load on the source
- 9 out of 10
- Setup and privileges
- 4 out of 10
Why these scores for Debezium, log-based CDC
- Complete change capture 10 out of 10
- Reading the log captures every change including deletes and preserves change ordering, and this page names it the standard answer where complete change capture is the requirement.
- Latency 8 out of 10
- Changes stream from the log as they are written, which is why this page pairs log-based CDC with low latency.
- Load on the source 9 out of 10
- Reading the log adds no query load to the tables, though a stalled connector leaves the log growing on the source.
- Setup and privileges 4 out of 10
- It needs replication-level privileges and logical decoding on PostgreSQL, which this page calls the most common blocker, plus monitoring of slot lag on the database side.
Debezium reads the database's own change log. The PostgreSQL WAL, the MySQL binlog, the Oracle redo log. Reading the log captures every change including deletes, preserves change ordering, and adds no query load to the tables. PostgreSQL needs logical decoding enabled for this: wal_level=logical.
Compare Kafka CDC: change data capture
JDBC source connector
Kafka Connect source connector
18 out of 40 Total
- Reads
- Table rows, by timestamp or incrementing column
- Runs on
- Kafka Connect
- Complete change capture
- 2 out of 10
- Latency
- 4 out of 10
- Load on the source
- 3 out of 10
- Setup and privileges
- 9 out of 10
Why these scores for JDBC source connector
- Complete change capture 2 out of 10
- Hard deletes are invisible to it and intermediate states between polls are missed, and this page records a race condition in which it skipped records silently.
- Latency 4 out of 10
- A change waits for the next poll interval before it is read.
- Load on the source 3 out of 10
- Each poll is real query load on the source tables.
- Setup and privileges 9 out of 10
- Setup is simpler and needs no database-level replication configuration.
A JDBC source polls tables with queries. It selects rows using a timestamp or incrementing column on an interval. Setup is simpler and needs no database-level replication configuration, but hard deletes are invisible to it, intermediate states between polls are missed, and each poll is real query load on the source.
Compare Kafka Connect
Production trade-offs and constraints
Database privileges. Log-based CDC needs replication-level access. On PostgreSQL the connector user needs the REPLICATION privilege, plus CREATE on the database when the pgoutput plug-in creates publications (Debezium PostgreSQL connector docs). On MySQL the connector user is granted SELECT, RELOAD, SHOW DATABASES, REPLICATION SLAVE and REPLICATION CLIENT (Debezium MySQL connector docs). This is a real conversation with the DBA before the first deployment, and it is the most common blocker.
Log retention versus connector downtime. The database retains its change log while a replication slot or binlog position is outstanding. A Debezium connector that stops consuming leaves the log growing on the source database, and on PostgreSQL an abandoned replication slot can fill the disk. Monitoring slot lag on the database side is part of running Debezium, not optional.
Delivery semantics. Debezium on Connect delivers at-least-once by default, so consumers deduplicate or write idempotently. Combined with Kafka’s transactional features it can provide exactly-once semantics for source records.
Schema changes. Because the log carries DDL as well as data, Debezium tracks schema evolution and emits change events without requiring schema changes on the source tables.
This pattern is standard at scale. Grab productionised Debezium CDC on Kafka Connect in 2021, and Wix runs Debezium as its source connector for row-level database changes, both documented in their own engineering write-ups.
Two constraints from Factor House’s own operating experience belong in any trade-off list. Thomas, one of Factor House’s engineers, hit Debezium changing its task configuration structure between versions, which broke tooling that assumed the old shape, so pin the connector version and diff the config contract on every upgrade. And a recurring pattern in Factor House’s support work: when a Debezium connector shows failed, the database being down is the usual cause, so surface erroring connectors with their underlying cause rather than restarting them blind.
Deployment modes: Connect cluster or Debezium Server
Debezium runs two ways. The standard deployment is as connectors inside a Kafka Connect cluster, which brings Connect’s fault tolerance, offset management and operational tooling.
Debezium Server is the standalone alternative: a single runtime that reads from a Debezium source and writes directly to a target without Kafka Connect, with sinks including Amazon Kinesis, Google Pub/Sub, Apache Pulsar, Azure Event Hubs and Redis. It suits teams whose target is not Kafka at all, or who want CDC without operating a Connect cluster. The trade is losing Connect’s task distribution and its ecosystem of sink connectors.
A third pattern exists inside stream processors: Flink CDC embeds the Debezium engine directly in a Flink source, snapshotting existing tables and then switching to the transaction log, with no Connect cluster in the path.
On the runtime choice itself, the rule this page applies is to count the operational models you are willing to own. A shared Connect cluster amortises operations across every pipeline you have, and Debezium Server earns its place only where Kafka is not the destination. If you are already running Kafka, the Connect-cluster mode keeps CDC inside the operational model you already run, and the worked MongoDB configuration shows what that looks like in practice.
For regulated industries and enterprise teams that run Debezium connectors on a shared Connect cluster, Factor House’s Kpow manages those connectors from the UI, including creating, pausing, restarting and deleting them, and its Enterprise edition adds role-based access control, SSO, data masking for PII and a full audit log of every action. Kpow is self-hosted, running as a single container in your own environment.
FAQ
Does Debezium require Kafka?
The standard deployment runs Debezium connectors inside a Kafka Connect cluster, so Kafka is in the path. Debezium Server is the exception: a standalone runtime that writes directly to targets such as Amazon Kinesis, Google Pub/Sub, Apache Pulsar, Azure Event Hubs and Redis, with no Kafka at all.
Is Debezium production-ready?
Yes. Shopify, Grab and Wix all run Debezium on Kafka Connect in production, documented in their own engineering write-ups, and it is the standard answer where complete change capture with low latency is the requirement.
When is a JDBC source connector enough?
When the requirement is a periodic copy of slowly changing reference data. Polling misses hard deletes and intermediate states between polls, so anything needing complete change history belongs on log-based CDC.
How these options were scored
Every option is scored from 0 to 10 on each criterion, from the evidence and sources this page cites, and the reason for each score is on its card. Each criterion counts once, for a total out of 40. The options are listed by total.