Debezium is an open-source platform for change data capture (CDC) - the practice of streaming every insert, update, and delete out of a database the moment it happens, rather than re-querying for changes on a schedule. It reads the database's own transaction log (the MySQL binlog, the PostgreSQL write-ahead log, the MongoDB oplog) and turns each committed change into an event. Built on Kafka Connect, it has become the default open-source answer to "how do I get my database changes into Kafka without hammering the source."
How log-based CDC works
Most naive change-tracking polls a table for rows where updated_at is recent. That misses deletes, misses intermediate states, and adds load to the very database you're trying to protect. Debezium instead taps the transaction log the database already writes for its own recovery. Because the log records every committed change in order, Debezium captures deletes, preserves ordering, and reads from a low-cost source the database maintains anyway. Each change becomes a structured event carrying the row's before and after state, the operation type, and metadata like the source table and log position.
Connectors and deployment
Debezium ships connectors for MySQL, PostgreSQL, MongoDB, SQL Server, Oracle, Db2, and others. The common deployment runs them as Kafka Connect source connectors, landing change events in Kafka topics - one topic per table by convention. For teams not on Kafka, Debezium Server is a standalone runtime that can sink changes to Kinesis, Google Pub/Sub, Pulsar, or Redis Streams, and the embedded engine lets a Java application consume changes directly as a library.
The patterns that matter
Two ideas come up constantly. The outbox pattern solves the dual-write problem: instead of writing to a database and a message broker separately (and risking one succeeding while the other fails), a service writes to its database and to an "outbox" table in the same transaction, and Debezium streams the outbox to Kafka - guaranteeing the event matches the committed state. Initial snapshots handle history: when a connector starts, it can snapshot existing rows before switching to live log streaming, so consumers get the full dataset, not just changes from now on.
Where it fits
- Replicating database changes into a warehouse, search index, or cache in near real time.
- Microservices that need reliable event publishing via the outbox pattern.
- Migrations and zero-downtime cutovers where the old and new systems must stay in sync.
When to look elsewhere
Debezium is powerful but operationally real: you run Kafka Connect, manage connector configs, handle schema changes, and tune snapshots for large tables. Managed CDC services like Fivetran (via its HVR engine), Striim, or cloud-native options such as AWS DMS trade flexibility and cost for someone else handling the plumbing. If you want changes in a warehouse and never plan to touch Kafka, a managed ELT tool may be the shorter path.
How it compares
Debezium owns the open-source CDC niche the way few tools own their category - it is the engine inside many commercial products. It pairs naturally with Confluent Platform for schema governance over the change topics, and feeds the same downstream systems as batch tools like Fivetran - just continuously instead of on a schedule. To understand the Kafka side it depends on, the Apache Kafka course covers Connect and topic design directly.
Frequently asked questions
Is Debezium free? Yes - it is open source under the Apache 2.0 license. You pay only for the infrastructure (Kafka Connect, brokers) you run it on.
Does Debezium require Kafka? Not strictly. The common setup uses Kafka Connect, but Debezium Server and the embedded engine let you stream changes without a Kafka cluster.
What databases does Debezium support? MySQL, PostgreSQL, MongoDB, SQL Server, Oracle, Db2, Cassandra, and Vitess, among others, with varying maturity per connector.