GUIDE

Change Data Capture (CDC) — Complete Guide

Q: Does CDC impact the performance of my source database?

Log-based CDC reads from the database's write-ahead log (WAL) or binary log, which is already written as part of normal operations. The overhead is minimal — typically less than 5% CPU impact. It is significantly lighter than polling approaches that execute repeated SELECT queries against production tables.

Q: Can I use CDC without Kafka or a message broker?

Yes. RisingWave supports direct CDC ingestion from PostgreSQL, MySQL, and MongoDB without requiring Kafka or Debezium. The database connects directly to the source database's replication log, reducing infrastructure complexity and operational overhead.

Q: How does CDC handle schema changes in the source database?

Schema changes like adding or dropping columns require coordination. RisingWave supports evolving schemas by allowing you to update source definitions and materialized views. Additive changes (new columns) are straightforward; destructive changes (dropped columns) may require recreating downstream views.

Q: What is the difference between CDC and database replication?

Database replication copies data to create identical replicas for high availability or read scaling. CDC captures changes as a stream of events that can be transformed, filtered, joined, and routed to different downstream systems. CDC is replication plus transformation — it enables real-time analytics and event-driven architectures, not just copies.

Change Data Capture streams every INSERT, UPDATE, and DELETE from your database in real-time. Learn how CDC works, why it beats dual writes, which databases support it, and how to build CDC pipelines with RisingWave.

Try RisingWave Free Streaming Database Guide

Log-Based

Zero App Changes

CDC reads the database transaction log directly — no triggers, no application-level event publishing needed

<5%

CPU Overhead

Reading the WAL/binlog adds minimal load because the log is already being written by normal operations

Sub-Second

Change Delivery

Changes are captured and delivered in real-time as they are committed to the source database

Direct

No Kafka Required

RisingWave reads PostgreSQL, MySQL, and MongoDB change logs natively without middleware

Why CDC

Why is CDC better than polling, triggers, or dual writes?

Polling wastes resources by repeatedly querying for changes. Triggers add latency and couple change detection to the source database. Dual writes create consistency risks when one write succeeds and the other fails. Log-based CDC avoids all three problems: it is efficient, decoupled, and guarantees that every committed change is captured exactly once.

Approach	Latency	Source Impact	Consistency	Captures Deletes
Polling	Seconds to minutes	High (repeated queries)	Eventual (may miss changes)	No
Triggers	Low	High (runs in transaction)	Strong (same transaction)	Yes
Dual Writes	Low	Medium (extra write)	Weak (partial failure risk)	Yes
Log-based CDC	Sub-second	Minimal (reads WAL)	Strong (commit order)	Yes

→The database writes every change to its transaction log as part of normal operations — CDC reads this log asynchronously
→Each captured change includes the operation type (insert, update, delete), the affected row's before and after values, and a timestamp
→Changes are delivered in commit order, preserving transactional consistency across tables
→Downstream systems receive a continuous, ordered stream of changes they can apply, transform, or analyze

How It Works

How do you set up CDC pipelines with RisingWave?

RisingWave supports direct CDC ingestion from PostgreSQL, MySQL, and MongoDB without requiring Kafka or Debezium as intermediaries. You create a source with a single SQL statement specifying the connection details, and RisingWave begins reading the database's change log immediately. Materialized views then transform the CDC stream using standard SQL.

Direct PostgreSQL CDC

Connect to PostgreSQL's logical replication slot directly. No Debezium, no Kafka Connect, no connector infrastructure to manage.

Direct MySQL CDC

Read MySQL's binlog natively. RisingWave acts as a replication replica, receiving changes with minimal latency and overhead.

MongoDB CDC

Stream changes from MongoDB change streams directly into RisingWave for real-time transformations on document data.

Kafka CDC Formats

Also supports Debezium JSON, Canal, and Maxwell formats from Kafka for teams with existing connector infrastructure.

Getting Started

What is Change Data Capture and how does it work?

Change Data Capture (CDC) is a technique that identifies and captures every change made to data in a database — every INSERT, UPDATE, and DELETE — and delivers those changes as a real-time stream of events. Log-based CDC reads from the database's internal transaction log (WAL in PostgreSQL, binlog in MySQL), capturing changes without modifying application code or impacting query performance.

→Step 1: Enable logical replication on your source database (wal_level=logical for PostgreSQL, binlog_format=ROW for MySQL)
→Step 2: CREATE SOURCE in RisingWave with the connection details — host, port, database, table, credentials
→Step 3: CREATE MATERIALIZED VIEW to transform, filter, join, or aggregate the CDC stream in real-time
→Step 4: Query the materialized view for instant results, or CREATE SINK to push changes to downstream systems

Frequently Asked Questions

Does CDC impact the performance of my source database?

Can I use CDC without Kafka or a message broker?

How does CDC handle schema changes in the source database?

What is the difference between CDC and database replication?

Ready to build CDC pipelines?

Start streaming database changes with SQL in minutes.

Start Building CDC Pipelines

PostgreSQL CDC Tutorial →Streaming SQL Guide →