RisingWave vs Debezium: CDC Without the Kafka Infrastructure

Not always. Debezium is the right choice when you need CDC events in Kafka for fan-out to multiple independent consumers — microservices, search indexes, and data lakes all reading the same topic. RisingWave replaces Debezium when your CDC destination is analytics: it reads directly from the database using the Debezium Embedded Engine, processes events with SQL, and serves results — no Kafka required.

Yes. RisingWave's CDC connectors for MySQL and SQL Server are powered by the Debezium Embedded Engine — the same battle-tested library that underlies Debezium, running in-process without Kafka. For PostgreSQL, RisingWave reads the WAL directly via logical replication. This means RisingWave inherits Debezium's CDC reliability without requiring you to operate Kafka or Kafka Connect.

Yes. A common hybrid pattern is: database → Debezium → Kafka → RisingWave (as a Kafka consumer). Debezium handles fan-out while RisingWave provides SQL analytics on the same events. RisingWave can read Debezium-formatted Kafka topics natively with FORMAT DEBEZIUM ENCODE JSON — no second replication slot needed.

RisingWave natively supports CDC from PostgreSQL (via logical replication), MySQL and SQL Server (via Debezium Embedded Engine), and MongoDB (via change streams). It also supports AWS Aurora, RDS, and Google Cloud SQL variants of these databases.

No. RisingWave CDC is configured entirely in SQL. A single CREATE SOURCE statement connects to your database and starts streaming changes. There is no Kafka Connect topology, no connector JSON files, no schema registry, and no consumer group management.

RisingWave handles upstream schema changes more gracefully than the Debezium + Kafka stack. Adding a column to a source table propagates automatically; there is no connector restart, schema registry update, or risk of serialization errors downstream. The materialized view is updated transparently.