RisingWave vs Debezium: Different Tools, Different Jobs

RisingWave and Debezium are not competitors. Debezium is a CDC pipeline tool: it reads database logs and ships change events to Kafka. RisingWave is a streaming database: it ingests change events (using Debezium's own engine internally) and lets you query them with SQL. Choosing between them depends on what you need to do with your CDC data, not which tool is "better."

What Each Tool Actually Does

Debezium solves one problem extremely well: reliably capturing every row-level change from a source database and making those changes available as a stream of events. Its native output is Kafka topics. It does not store state, run queries, or maintain aggregations. It is a pipeline, not a database.

RisingWave is a PostgreSQL-compatible streaming database. It can ingest CDC streams (directly from source databases, or from Kafka topics that Debezium has already populated), and it allows you to write SQL queries — including materialized views — that stay continuously up to date as data changes.

RisingWave's built-in CDC connectors use the Debezium Embedded Engine internally. When you connect RisingWave directly to PostgreSQL or MySQL, Debezium's engine is doing the log reading. The difference is that the output flows into RisingWave's SQL engine rather than into Kafka.

The Architecture Comparison

Debezium Standalone pipeline:

Source DB → Debezium (Kafka Connect) → Kafka topics → Consumer A
                                                    → Consumer B
                                                    → Consumer C

RisingWave with built-in CDC:

Source DB → RisingWave (Debezium Embedded) → Materialized Views → SQL queries

RisingWave consuming from Debezium's Kafka output:

Source DB → Debezium → Kafka topics → RisingWave → Materialized Views → SQL queries

All three are valid architectures. The right one depends on what else is consuming your CDC stream.

When Debezium Is the Right Choice

Fan-out to multiple independent consumers. Kafka's consumer group model allows dozens of independent services to read the same change stream at their own pace. If your CDC events need to feed a search index, a data warehouse, a cache invalidation service, and a stream processor simultaneously, Debezium + Kafka is the natural fit — the Kafka log acts as a shared, replayable bus for all consumers.

Non-SQL destinations. Debezium + Kafka Connect sinks can write change events to Elasticsearch, Redis, S3, Snowflake, BigQuery, and many other systems via connector plugins. If your pipeline's primary output is raw events to a non-SQL system, Debezium with Kafka Connect is the right tool.

Long-term event replay. Kafka retains events for a configurable retention period — useful for late-joining consumers, debugging, and compliance audit trails. If long-term event retention is a primary requirement, the Kafka layer is purpose-built for this.

Schema registry integration. The Debezium + Kafka ecosystem integrates with Confluent Schema Registry or AWS Glue Schema Registry for Avro/Protobuf schema management across many consumers. For multi-consumer pipelines with strict schema governance, this ecosystem is mature and well-supported.

What RisingWave Does That Debezium Doesn't

SQL queries on live CDC data. This is the defining capability. With RisingWave, you can write:

CREATE MATERIALIZED VIEW revenue_by_region AS
SELECT
    c.region,
    SUM(o.total_amt)   AS total_revenue,
    COUNT(DISTINCT o.customer_id) AS unique_customers
FROM orders_cdc o
JOIN customers_cdc c ON o.customer_id = c.id
WHERE o.status = 'completed'
GROUP BY c.region;

This view is maintained incrementally. As new orders arrive from the CDC stream, the aggregation updates in place — no batch recomputation, no full table scans. Debezium has no SQL layer; it produces events, not query results.

Joins across CDC streams. You can join multiple CDC sources in RisingWave. Joining two Kafka topics from Debezium in pure Kafka requires a stream processor like Flink or ksqlDB. RisingWave is that stream processor, built in.

Postgres-compatible SQL interface. RisingWave exposes a PostgreSQL wire protocol. Any tool or language that connects to PostgreSQL works with RisingWave — psql, JDBC, SQLAlchemy, Metabase, Grafana, Superset.

Simpler operational footprint. For teams without existing Kafka infrastructure, RisingWave's built-in CDC eliminates the need to operate Kafka brokers, Kafka Connect workers, and connector configurations.

Side-by-Side Comparison

When to Use Debezium

• You need to propagate changes to multiple downstream systems from a single source.
• Your team already operates Kafka and the marginal cost of a Debezium connector is low.
• Downstream consumers include non-SQL targets: search engines, caches, data warehouses, cold storage.
• You need a durable, replayable event log that outlives any individual consumer.
• You want fine-grained control over the Kafka topic schema (Avro, Protobuf, JSON with schema registry).

When to Use RisingWave

• You want to query live CDC data with SQL — aggregations, joins, filters, window functions.
• Your team wants incremental materialized views that stay fresh without scheduled batch jobs.
• You don't operate Kafka and don't want to start.
• The CDC stream has one destination: analytics, dashboards, or application queries.
• You want a PostgreSQL-compatible interface so existing BI tools connect without modification.

Using Both Together

Debezium and RisingWave pair well. A common production pattern:

1. Debezium writes change events from PostgreSQL to Kafka (for fan-out, audit, and replay).
2. RisingWave subscribes to those Kafka topics using its Kafka source connector.
3. RisingWave maintains materialized views for analytics and real-time dashboards.

In this pattern, RisingWave is not using its built-in CDC connector at all — it is treating Debezium's Kafka output as its input. The two tools complement each other rather than compete.

-- RisingWave consuming from Debezium's Kafka output
CREATE SOURCE orders_from_kafka WITH (
    connector = 'kafka',
    topic = 'shop_server.public.orders',
    properties.bootstrap.server = 'kafka:9092',
    scan.startup.mode = 'earliest'
) FORMAT DEBEZIUM ENCODE JSON;

CREATE MATERIALIZED VIEW daily_order_counts AS
SELECT
    DATE_TRUNC('day', created_at) AS day,
    COUNT(*) AS order_count
FROM orders_from_kafka
GROUP BY 1;

FAQ

Do I need Debezium to use RisingWave CDC? No. RisingWave has built-in CDC connectors for PostgreSQL and MySQL that use the Debezium Embedded Engine internally. You do not deploy or configure Debezium separately.

Can RisingWave replace Debezium in my existing Kafka architecture? For analytics and querying use cases, yes — RisingWave's built-in CDC connector eliminates the Kafka layer entirely and gives you a SQL interface directly. For multi-consumer fan-out architectures where Kafka feeds many independent systems, the typical pattern is to keep Debezium + Kafka for distribution, and add RisingWave as one of the consumers for the analytics/query layer.

Is Debezium faster than RisingWave's CDC connector? They use the same underlying log-reading code (the Debezium Embedded Engine). The latency difference between the two approaches is in the pipeline depth: Debezium + Kafka adds broker round-trips that RisingWave's embedded approach avoids.

Does RisingWave support Debezium's JSON event format? Yes. When consuming Kafka topics populated by Debezium, RisingWave supports FORMAT DEBEZIUM ENCODE JSON and FORMAT DEBEZIUM ENCODE AVRO in its CREATE SOURCE statement.

What if I start with RisingWave and later need Debezium? The two are independent. You can run Debezium Standalone against the same source database with a separate replication slot. Both will receive the full change stream independently.