Debezium

Overview

Debezium is the open-source answer to change data capture, and the only free one among the serious options. It monitors databases and streams every row-level change in the order it was committed.

Capture is always transaction-log based, using each database's own native interface: logical decoding on Postgres, the binlog on MySQL, the transaction log on SQL Server, the oplog on MongoDB. There is no trigger-based or query-based path at all.

Oracle is the exception worth knowing about, with three adapters. LogMiner is the default, OpenLogReplicator reads redo logs directly, and the XStream option is, in Debezium's own words, a commercial component of Oracle GoldenGate, so that route needs a GoldenGate licence.

The most important structural fact is that it is not one deployable product but connectors plus three runtimes: a Kafka Connect plugin, a standalone Debezium Server needing no Kafka at all, and an embeddable Java library.

Debezium Server is underrated. It streams to more than twenty sinks including Kinesis, Pub/Sub, Pulsar, Event Hubs, Redis, RabbitMQ, Iceberg and vector stores, which removes Kafka from the architecture entirely.

Delivery has changed and older descriptions are wrong. Exactly-once is now supported on all six core relational and document connectors, though it needs Kafka Connect 3.3 or later in distributed mode with specific worker settings.

Snapshots are sophisticated. Incremental snapshots chunk a table and process it while streaming continues, tracked by watermarks and resumable, and ad-hoc snapshots can be triggered through a signalling table.

The clearest gaps against the commercial tools are coverage and writers. There are no mainframe sources, no SAP, Sybase or Teradata, and no first-party warehouse sinks; Snowflake, BigQuery and Databricks are not published.

Its direction is the Debezium Management Platform, a pipeline user interface with OpenTelemetry monitoring, with alerting and access management still on the roadmap.

Key features and capabilities

The same headings are used for every change data capture & replication entry, so two tools can be read side by side.

How changes are captured

• Transaction-log based throughout, using each database's native interface; no trigger or query-based path
• Oracle offers three adapters, LogMiner by default, OpenLogReplicator, and XStream which needs a GoldenGate licence
• An initial snapshot records the log position then scans tables, with six snapshot modes
• Incremental snapshots chunk tables and run while streaming continues, resumable through watermarks
• Ad-hoc snapshots are triggered through a signalling table or a Kafka signal topic

Source databases

• PostgreSQL 14 to 18, MySQL 8.0 to 9.1, MariaDB, SQL Server 2017 to 2022, Oracle 19c to 26ai and Db2
• MongoDB 6 to 8, Cassandra and Spanner, with Vitess, Informix and CockroachDB incubating
• No mainframe sources at all, so no IMS, VSAM or Db2 for z/OS
• No SAP HANA, Sybase, Teradata, SAP application or Salesforce connectors
• Only databases using UTF-8 character encoding are supported

Targets

• Through Kafka Connect, any Kafka topic and then the whole Connect sink ecosystem
• Debezium Server streams to more than twenty sinks without Kafka, including Kinesis, Pub/Sub and Pulsar
• Also Event Hubs, Redis Streams, NATS, RabbitMQ, RocketMQ, HTTP, JDBC and Apache Iceberg
• Vector stores Milvus and Qdrant are supported sinks
• No first-party warehouse writers; Snowflake, BigQuery, Databricks and Delta are not published

Delivery and consistency guarantees

• The default is at-least-once, with duplicates possible around a crash before the offset was recorded
• Exactly-once is supported on MariaDB, MongoDB, MySQL, Oracle, PostgreSQL and SQL Server
• It requires Kafka Connect 3.3 or later, distributed mode, and specific worker and connector settings
• Debezium itself notes it remains unclear whether the Kafka implementation covers every edge case
• Events within a topic are totally ordered, and transaction metadata can be emitted

Handling schema changes

• Connectors keep a schema history and every change event carries the record's schema
• PostgreSQL logical decoding does not support DDL, so the connector cannot report schema changes on it
• Schema registry integration comes through Kafka Connect converters rather than a Debezium feature
• Generated column values cannot be captured with the native Postgres plugin
• A schema history that no longer matches the database forces a fresh snapshot

Monitoring and recovery

• JMX metrics per connector across snapshot, streaming and schema history categories
• Prometheus and Grafana export is documented, though the dashboards are maintained on a best-effort basis
• Offsets live in the Connect offset store, so a restart resumes where it left off
• Failed tasks are handled by Kafka Connect's own lifecycle; there is no Debezium supervisor or alerting
• High availability is inherited from Connect distributed mode, which means failover rather than parallel scale-out

Where it runs and what it costs

• Three runtimes, a Kafka Connect plugin, the standalone Debezium Server, or an embedded Java library
• A Kubernetes operator manages Debezium Server, with Helm charts published and listings in OperatorHub
• For Kafka Connect on Kubernetes the usual route is Strimzi rather than a Debezium operator
• No managed service from the project, so hosting means a third party or your own operations
• Java 17 or later for connectors, 21 or later for the server and operator

Pricing

Open sourceFree, Apache 2.0

Free, and genuinely so: Apache 2.0 with no commercial edition, no paid tier and no support contract published by the project at all. The community channels are a chat room, a Google group and GitHub. A buyer wanting a supported build has to go to a third party that distributes or hosts Debezium, and none of those is first-party to the project. One cost trap to note: using Debezium against Oracle through the XStream adapter requires a GoldenGate licence, so Debezium on Oracle is not free in every configuration.

Vendor pricing page →

Demos and videos

• Debezium Platform complete walkthrough Product demo · YouTube
• Create, edit and remove a pipeline Tutorial · YouTube

About Commonhaus Foundation

Debezium moved to the Commonhaus Foundation in December 2024, announced that November, so it is no longer a Red Hat-stewarded project in governance terms. Red Hat sponsored it exclusively from its start in 2015 and donated the trademark and domain names, though not copyright, and says its involvement is unchanged. Governance is now the project's own, with contributors, committers who can merge, and a steering committee holding final authority, deciding by lazy consensus or explicit majority. The core repository has around 13,000 stars and roughly 365 identified contributors. Licence is Apache 2.0.

Founded 2016 · debezium.io