Change Data Capture Cheat Sheet

Explains log-based versus trigger-based CDC approaches and shows how to configure Debezium with PostgreSQL logical replication for streaming changes.

2 PagesAdvancedMar 12, 2026

CDC Approaches

The main techniques for capturing row-level changes as they happen.

Log-based CDC- Reads the database's transaction log (WAL, binlog, redo log) to capture every insert/update/delete with minimal impact on the source. Used by Debezium and AWS DMS.
Trigger-based CDC- Database triggers write changes to a shadow/audit table on every DML statement. Simple to set up but adds write overhead to the source database.
Query-based (polling)- Periodically queries rows using an updated_at timestamp or incrementing ID column. Misses hard deletes and adds detection latency.
Snapshot + streaming- CDC tools first take a consistent initial snapshot of existing data, then switch to streaming log changes going forward.
Outbox pattern- The application writes domain events to an outbox table in the same transaction as the business data; CDC streams that table to avoid dual-write inconsistency.

Debezium Connector Config

json

{  "name": "orders-connector",  "config": {    "connector.class": "io.debezium.connector.postgresql.PostgresConnector",    "database.hostname": "postgres",    "database.port": "5432",    "database.user": "debezium",    "database.password": "dbz",    "database.dbname": "shop",    "topic.prefix": "shop",    "table.include.list": "public.orders,public.customers",    "plugin.name": "pgoutput"  }}

PostgreSQL Logical Replication Setup

Prerequisites Debezium needs on the source PostgreSQL database.

sql

-- postgresql.conf must have:-- wal_level = logical-- Create a publication for the tables you want to captureCREATE PUBLICATION orders_pub FOR TABLE orders, customers;-- Debezium creates a replication slot automatically, or create manually:SELECT pg_create_logical_replication_slot('orders_slot', 'pgoutput');-- Grant replication privilege to the CDC userALTER ROLE debezium WITH REPLICATION;

Register the Connector

Deploy the connector via the Kafka Connect REST API and check its status.

bash

curl -X POST http://localhost:8083/connectors \  -H "Content-Type: application/json" \  -d @orders-connector.json# Check connector and task statuscurl http://localhost:8083/connectors/orders-connector/status

Key Concepts

Terminology you'll run into when operating a CDC pipeline.

Debezium- Open-source, Kafka Connect-based CDC platform with log-based connectors for Postgres, MySQL, MongoDB, SQL Server, and Oracle.
Topic per table- Debezium publishes one Kafka topic per captured table by default (<topic.prefix>.<schema>.<table>), with each message carrying before/after row state.
Replication slot- A PostgreSQL server-side object that retains WAL segments until the consumer has read them — prevents data loss but risks disk bloat if the consumer stalls.
At-least-once delivery- Most CDC pipelines guarantee at-least-once delivery; downstream consumers must handle duplicate events idempotently.
Schema evolution- CDC connectors typically emit schema change events so consumers can adapt automatically when columns are added or dropped upstream.

Pro Tip

Monitor replication slot lag closely — an idle or crashed CDC consumer leaves the WAL replication slot open, causing WAL files to accumulate on the primary until it runs out of disk space, even though the database itself looks perfectly healthy.

Was this cheat sheet helpful?

Vector Databases (Pinecone/Weaviate) Cheat Sheet

Database Security Best Practices Cheat Sheet

Explore Topics

#ChangeDataCapture#ChangeDataCaptureCheatSheet#Database#Advanced#CDCApproaches#DebeziumConnectorConfig#PostgreSQL#Logical#Databases#CheatSheet#SkillVeris

Sri Hayavadhana Info-Tech

Professional Web Designing Services