Debezium

Open-source change data capture: connectors that read a database’s transaction log and emit every committed insert, update and delete as an event, usually into Kafka.

What it is: Change data capture,ETL & ELT pipelines
Type: Open source
Made by: Commonhaus Foundation; core team at IBM, formerly Red Hat
License: Apache 2.0
Facts checked: 23 October 2026

What it is

Debezium reads the log a database already keeps for replication and turns each committed row change into an event. Its PostgreSQL connector streams from a logical replication slot through the built-in pgoutput plugin (or the decoderbufs plugin); its MySQL connector reads the binlog. Other connectors cover MariaDB, MongoDB, Oracle, SQL Server, Db2, Cassandra, Vitess, Spanner, Informix and more. On first start a connector takes a consistent snapshot of the existing rows, emitted as r (read) events, then streams from the log position it noted before the scan. Each event carries the row’s key and a value with before, after, op (c, u, d or r) and a source block with metadata such as the PostgreSQL LSN and transaction id. The connector records that log position as its offset, so after a restart it carries on where it stopped.

There are three ways to run it. Most people deploy the connectors on Apache Kafka Connect, which writes each table’s changes to its own topic, named <topic.prefix>.<schema>.<table> by default. Debezium Server is a standalone application configured with one application.properties file that sends the same events to Amazon Kinesis, Google Cloud Pub/Sub, Apache Pulsar, Redis streams, NATS, RabbitMQ, Apache Iceberg and other sinks, without Kafka. The Debezium Engine is a Java library you embed in your own application. Debezium is free under Apache 2.0. Red Hat sponsored it from its first commit in November 2015; in November 2024 the project announced it was joining the Commonhaus Foundation, and its core team moved from Red Hat to IBM in July 2025. Version 3.7 came out in September 2026.

Why teams pick it

Captures every committed change, including deletes, from the log, without polling tables or adding triggers
One event format across many databases, with the old and new row and the log position in each event
Snapshot then stream: existing rows and later changes arrive in one ordered feed, and offsets let a restarted connector resume
Runs on Kafka Connect, as a standalone server with more than 20 sinks, or embedded as a Java library

Watch out for

Some database setup is needed: PostgreSQL must run with wal_level=logical, and the default decoderbufs plugin has to be installed unless you set plugin.name to pgoutput
A PostgreSQL replication slot keeps all WAL that Debezium has not confirmed, even while Debezium is down, so a stalled connector can fill the database’s disk; quiet captured tables need heartbeats to let the slot advance
PostgreSQL logical decoding does not report DDL, so schema changes do not arrive as events, and with the default replica identity a table without a primary key emits no update or delete events
The usual deployment means running Kafka, Kafka Connect and often a schema registry; Debezium Server removes Kafka but runs one source connector per instance

How it fits with other technologies

What Debezium uses

What uses Debezium

A PostgreSQL connector, registered with Kafka Connect’s REST API (POST /connectors) · json

{
  "name": "fulfillment-connector",
  "config": {
    "connector.class": "io.debezium.connector.postgresql.PostgresConnector",
    "plugin.name": "pgoutput",
    "database.hostname": "192.168.99.100",
    "database.port": "5432",
    "database.user": "postgres",
    "database.password": "postgres",
    "database.dbname": "postgres",
    "topic.prefix": "fulfillment",
    "table.include.list": "public.inventory"
  }
}

See it in a real stack

No architecture uses Debezium yet. Drop it into the playground and wire it up yourself.Open playground →

Where it came from2015–2026

Kafka Connect had just been announced as a framework for moving data in and out of Kafka. Randall Hauch, at Red Hat, saw it as the base on which “practical and reusable” change data capture could be built, and Red Hat let him start an open-source project around CDC connectors. The first commit landed in November 2015, and Debezium 0.1 shipped on 18 March 2016 with one connector, for MySQL, which read the binlog and ran on Kafka Connect, plus a library for embedding connectors in an application.

In 2017 Hauch moved to Confluent and handed the lead to Gunnar Morling. Debezium 1.0 followed on 18 December 2019, when the MySQL, PostgreSQL, MongoDB and SQL Server connectors were called stable; Oracle and Cassandra were still incubating.

Red Hat was Debezium’s only sponsor until November 2024, when the team announced it would join the Commonhaus Foundation, which also hosts Hibernate and Quarkus. In April 2025 the team said it would move with Red Hat’s middleware engineers to IBM that July, and that IBM would keep contributing to the open-source project.

Why it’s built this way

Read the database’s own log instead of querying tables: The log already holds every committed change in order, including deletes, so a reader adds little load and misses nothing between polls.
Build on Kafka Connect: Connect already handled distributing connectors over workers, storing offsets and restarting failed tasks, so Debezium only had to write the database-specific readers.
Snapshot first, then stream from a recorded position: Databases purge old log segments, so a new consumer cannot rebuild a table from the log alone; a snapshot plus the log position taken before it gives a complete, gap-free copy.

Timeline

2015
First commit, at Red Hat, in November
2016
Debezium 0.1 ships a MySQL connector for Kafka Connect
2017
Randall Hauch hands the project lead to Gunnar Morling
2019
Debezium 1.0: MySQL, PostgreSQL, MongoDB and SQL Server connectors are stable
2024
The project announces it is joining the Commonhaus Foundation
2025
The Debezium team moves from Red Hat to IBM in July
2026
Debezium 3.7 is released in September

Sources7 · facts checked 23 October 2026

Improve this page on GitHub