Debezium

CDC/Streaming

36.1
Overall Score
433 quotes

Dimension Scores

Sync Reliability 25
97 quotes
Connector Breadth 58
137 quotes
Performance at Scale 25
104 quotes
Setup & Ease of Use 42
95 quotes

Overview

Debezium is a Red Hat-sponsored open-source project that has become the de facto CDC primitive for teams building event-driven and streaming data architectures. It connects to database transaction logs (MySQL binlog, PostgreSQL WAL, SQL Server CDC, Oracle LogMiner, MongoDB oplog) and publishes row-level change events to Kafka topics via Kafka Connect. For teams that need real-time database replication without polling, Debezium is the most widely deployed open-source option.

The appeal is architectural: Debezium integrates cleanly with the Kafka ecosystem, enabling downstream consumers (Flink, ksqlDB, Spark Streaming, warehouse connectors) to process change events at sub-second latency. It covers all major relational databases and MongoDB, handles initial snapshots for existing data, and produces well-structured change event schemas. The Red Hat backing and large community mean active maintenance and connector quality that exceeds most commercial CDC alternatives for supported databases.

The operational complexity is significant and consistently flagged by practitioners. Running Debezium in production requires Kafka (or a Kafka-compatible broker), Kafka Connect infrastructure, schema registry, and DBA cooperation for log retention configuration. Connector restarts during peak traffic periods can trigger multi-hour backlog recovery windows. Teams without existing Kafka expertise face a steep ramp — the three-hop architecture (database log → Kafka Connect → Kafka → sink) introduces multiple failure surfaces and observability gaps that managed alternatives eliminate.

Strengths

  • Real-time CDC from database transaction logs — no polling, minimal source database load
  • Covers all major databases: MySQL, PostgreSQL, SQL Server, Oracle, MongoDB, Cassandra
  • Deep Kafka ecosystem integration — native Kafka Connect framework
  • Open-source with strong Red Hat sponsorship — active maintenance and free to use
  • Initial snapshot capability for bootstrapping CDC from existing data

Limitations

  • Requires full Kafka infrastructure (broker, Kafka Connect, schema registry) — significant operational burden
  • Connector restarts during high-volume periods can trigger multi-hour backlog recovery
  • DBAs must enable and configure log retention on source databases — often a political blocker
  • Three-hop architecture (log → Connect → Kafka → sink) introduces multiple failure surfaces
  • No built-in observability or monitoring — requires additional tooling to detect lag or failures

Pricing Model

Debezium is open-source and free to use. Infrastructure costs (Kafka cluster, Kafka Connect workers, schema registry, monitoring) are the real cost — typically meaningful compute and storage spend depending on change volume. Managed Debezium-as-a-service is available through Confluent Platform and AWS MSK, at those vendors' pricing.

User Evidence

Positive hn
"PG-Capture lets you source events from Debezium, WAL-Listener, PG directely..."
View original →
Positive hn
"Debezium pipes it into Kafka, allowing you to leverage Kafka while still using MySQL as your primary data store. (Or Postgres, which Debezium includes support for.)"
View original →
Negative hn
"Debezium also does not solve the problem it, and from DBA point of view it is a blocker for adoption."
View original →
Negative hn
"We tested kafka connect and felt it was hard to work with. Had to setup 3 steps a) stream changes to kafka b) sync raw changes from kafka to the target data-store c) normalize the raw changes to the target."
View original →
Negative hn
"easy to setup and work with - no dependence on kafka, zookeper, kafka connect"
View original →
Negative hn
"Connectors restarting more often than expected. Backlog recovery during peak traffic could take hours."
View original →

Last updated: Jun 17, 2026