---
title: "Debezium"
description: "Debezium is an open-source distributed platform for change data capture (CDC), which streams row-level insert, update, and delete events out of databases in real time."
canonical: "https://motherduck.com/glossary/debezium/"
related:
  - title: "DuckLake Architecture Deep Dive"
    url: "https://motherduck.com/blog/ducklake-architecture-deep-dive/"
  - title: "DBeaver | MotherDuck Docs"
    url: "https://motherduck.com/docs/integrations/sql-ides/dbeaver/"
  - title: "Estuary + MotherDuck Integration | DuckDB Analytics"
    url: "https://motherduck.com/ecosystem/estuary/"
gated_asset:
  title: "DuckLake on MotherDuck"
  url: "https://motherduck.com/product/ducklake/"
---

# Debezium

> Debezium is an open-source distributed platform for change data capture (CDC), which streams row-level insert, update, and delete events out of databases in real time.

## Overview

Debezium is an open-source platform for change data capture: it monitors a database's internal transaction/commit log and turns every insert, update, and delete into a structured event, streamed out in real time rather than being discovered later by polling. Debezium was created at Red Hat, which began the project in 2016, and has run as an open-source community project ever since. As of late 2024, Debezium's governance moved from being hosted primarily through Red Hat's infrastructure to the Commonhaus Foundation, a vendor-neutral open-source foundation, while Red Hat remains an active contributor.

<glossary-callout video="agentic-data-engineering-pipelines-ai" />

## How it works

Debezium connectors are most commonly deployed as source connectors on top of **Kafka Connect**, though a standalone "embedded" mode also exists for running Debezium without Kafka. Each connector reads a specific database's native change log (e.g., MySQL's binlog, Postgres's logical replication slot, MongoDB's oplog) and emits one event per row change, capturing the before and after state of the row.

```json
{
  "before": {"id": 101, "status": "pending"},
  "after": {"id": 101, "status": "shipped"},
  "source": {"table": "orders", "db": "shop", "ts_ms": 1715000000000},
  "op": "u"
}
```

Here `op: "u"` marks an update; Debezium uses `c`, `u`, `d`, and `r` to represent creates, updates, deletes, and initial snapshot reads respectively.

## Why it matters

Log-based CDC avoids two problems with polling a database on a schedule: it misses no intermediate states (a row updated three times between polls still produces three events, not one), and it puts far less load on the source database than repeated `SELECT` scans. Debezium's event stream is commonly consumed to keep a downstream analytical store continuously in sync with an operational database, feed event-driven microservices, or populate a data lake with an accurate, ordered history of changes. Because Debezium publishes events through Kafka topics (or equivalent), a downstream consumer, such as a job that periodically materializes Parquet files, can be queried directly by an engine like DuckDB, or the events can ultimately land in a MotherDuck database for analysis.