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 I see teams stuck on “versus”, they are almost always really choosing between log-based CDC and something else, not between these two projects.
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. Our 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.
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.
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.
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 strongest argument for log-based CDC over query-based polling is a failure you cannot see. In our 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.
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 our own operating experience belong in any trade-off list. Thomas, one of our 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 we see in support: 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, my rule 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.
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.