Building Event-Driven Systems with PostgreSQL Logical Replication and Drasi
summary
Compares three concrete CDC paths: wal2json, Debezium with Kafka, and Drasi (CNCF sandbox) by running the same Locust load and measuring latency, WAL cost, and code size. wal2json and Drasi show ~2–3 ms end‑to‑end latency, Debezium runs ~500 ms due to Kafka hops; wal2json needs one replication slot per consumer, Drasi uses one slot with multiple continuous queries, Debezium uses one slot into Kafka for unlimited consumers. Demo includes config details (wal_level=logical, replication slots), WAL‑growth risk (example: 64 GB in an hour) and mitigations (max_slot_wal_keep_size, monitor pg_replication_slots, drop stalled slots).
AI-written summary · about
chapters (14)
- 0:00Music & introduction
- 0:21Three approaches to event streams
- 0:50Problems with polling, triggers, and dual writes
- 1:41CDC with WAL: the core idea
- 2:16Inside the WAL pipeline explained
- 3:05Setting up logical replication in Postgres
- 4:07Architecture overview: three CDC paths
- 6:01Benchmark setup for fair comparison
- 7:52Demo: wal2json low-latency streaming
- 11:14Demo: Debezium and Kafka trade-offs
- 16:18Demo: Drasi filtering and fan-out
- 22:03Comparing latency, cost, and complexity
- 24:13Production risks: WAL growth and slots
- 25:49Choosing the right CDC approach
related talks
39mReliable Data Replication from Postgres on Kubernetes
42mWhy PostgreSQL people should care about Kafka and Debezium?
41mStreaming your database - Easier said than done?
38mA journey into postgresql logical replication
19mChange data capture with Debezium…and without
51mGeo-Distributed Postgres Replication Using Debezium
33mTransitioning from Debezium ElasticSearch to Postgres for Streamlined Resilience
30mChange Data Streaming Patterns in Distributed Systems