GUIDE

PostgreSQL CDC Tutorial

Q: Does PostgreSQL CDC affect production database performance?

RisingWave reads from PostgreSQL's write-ahead log (WAL) which is already written by the database. The performance impact is minimal — similar to adding a read replica. For high-throughput systems, you can configure RisingWave to read from a replica instead of the primary.

Q: What PostgreSQL versions does RisingWave CDC support?

RisingWave supports PostgreSQL 10 and above for CDC, including managed services like Amazon RDS, Amazon Aurora, Google Cloud SQL, Azure Database for PostgreSQL, and Supabase. Logical replication must be enabled on the source database.

Q: How does RisingWave handle the initial snapshot for CDC?

When you create a CDC source, RisingWave automatically performs an initial snapshot of the existing table data, then seamlessly transitions to streaming changes from the WAL. No manual bootstrapping or separate snapshot process is needed.

Q: Can I CDC from multiple PostgreSQL tables into one materialized view?

Yes. You can create CDC sources for multiple PostgreSQL tables and join them together in a single materialized view using standard SQL. This is one of the most powerful patterns — creating denormalized, always-fresh views across normalized source tables.

Capture every change from your PostgreSQL database in real-time. This tutorial shows how to set up CDC from PostgreSQL to RisingWave, create streaming materialized views on live data, and serve fresh results instantly.

Start Free CDC Complete Guide

WAL-Based

Zero Write Overhead

Reads the write-ahead log directly — no triggers, no polling, no impact on write operations

Direct

No Debezium Needed

RisingWave connects to PostgreSQL natively — no Kafka Connect or middleware infrastructure required

Auto

Initial Snapshot

Automatically loads all existing data first, then seamlessly transitions to streaming WAL changes

PG 10+

Wide Compatibility

Supports PostgreSQL 10+, including RDS, Aurora, Cloud SQL, Azure Database, and Supabase

How It Works

How does PostgreSQL CDC work under the hood?

PostgreSQL Change Data Capture works by reading the database's write-ahead log (WAL). Every INSERT, UPDATE, and DELETE is first written to the WAL before being applied to tables. CDC readers consume this log stream to capture a complete, ordered record of every change — without polling, triggers, or timestamp columns.

Approach	Write Overhead	Latency	Coverage	Integration
WAL-Based (RisingWave)	Zero	Sub-second	Every change	Native
Trigger-Based	2x writes	Low	Every change	Fragile
Poll-Based	Read load	Minutes	Misses deletes	Requires timestamp cols
Log-Based (Debezium)	Zero	Sub-second	Every change	Requires Kafka Connect

→PostgreSQL writes every data change to the WAL before committing to disk — this is the source of truth for CDC
→Logical replication decodes WAL entries into structured change events (INSERT, UPDATE, DELETE with before/after values)
→RisingWave creates a replication slot and continuously reads decoded changes with minimal impact on the source database
→Unlike trigger-based CDC, WAL-based CDC adds no overhead to write operations on the source
→Unlike poll-based CDC, WAL-based CDC captures every change — including intermediate updates and deletes

Use Cases

What can you build on top of PostgreSQL CDC streams?

PostgreSQL CDC streams unlock a wide range of real-time use cases that were previously impossible or prohibitively complex with batch ETL. By streaming changes from your operational database into RisingWave, you can build real-time dashboards, search indexes, cache layers, audit systems, and cross-service data products — all driven by SQL.

Real-Time Dashboards

Create materialized views that aggregate order counts, revenue, and metrics. Dashboards query RisingWave instead of hitting the production database.

Search Index Sync

Sink CDC changes to Elasticsearch or OpenSearch. Keep search indexes in sync with your database automatically, replacing fragile dual-write patterns.

Cross-Service Views

Join CDC streams from multiple PostgreSQL databases into unified materialized views. Build cross-service data products without tight coupling.

Audit & Compliance

Capture every change with before/after values. Build immutable audit logs and compliance reports that track who changed what and when.

Step-by-Step

How do you set up PostgreSQL CDC with RisingWave step by step?

Setting up PostgreSQL CDC with RisingWave requires three steps: enable logical replication on your PostgreSQL instance, create a CDC source in RisingWave pointing to your database, and define materialized views over the CDC stream. The entire process takes minutes and uses standard SQL throughout.

→Enable logical replication on PostgreSQL — set wal_level = logical in postgresql.conf and restart
→Create a publication for the tables you want to capture — run CREATE PUBLICATION on the PostgreSQL source
→Create a CDC table in RisingWave — use CREATE TABLE ... WITH ( connector = 'postgres-cdc' )
→RisingWave performs an automatic initial snapshot — all existing rows are loaded first
→Create materialized views over the CDC table — write SQL queries with joins, aggregations, and filters
→Query results via PostgreSQL protocol — connect any PostgreSQL client to RisingWave

Frequently Asked Questions

Does PostgreSQL CDC affect production database performance?

What PostgreSQL versions does RisingWave CDC support?

How does RisingWave handle the initial snapshot for CDC?

Can I CDC from multiple PostgreSQL tables into one materialized view?

Ready to stream PostgreSQL changes?

Start capturing database changes with SQL in minutes.

Start Streaming PostgreSQL Changes

CDC Complete Guide →Materialized Views →