How teams scaled Debezium: 2 real case studies
2 of the 94 engineering write-ups in our database mention Debezium in their stack. They come from 2 companies (Notion and Zalando) and were published between 2024 and 2025. 1 of the 2 state concrete scale numbers, for example "hundreds of event streams from Postgres" (Zalando). Each card below links to our short summary and the original post.
Contributing to Debezium: Fixing Logical Replication at Scale
Zalando's Fabric Event Streams provisions Debezium-in-embedded micro-apps so teams declare Postgres-sourced Kafka streams on Kubernetes; at peak the connectors handle hundreds of thousands of events per second across 100+ clusters, and have processed billions of events since 2018. Uncontrolled WAL growth on low-activity databases was the top operational issue until a pgjdbc keepalive flush advanced replication slots without table traffic. When newer Debezium hard-disabled that flush, Zalando contributed lsn.flush.mode (including connector_and_driver) and offset.mismatch.strategy (including trust_slot / trust_greater_lsn) so operators can opt into keepalive flushes while choosing whether the slot or the offset store wins on restart—both shipped in Debezium 3.4.0.Final.
Building and scaling Notion's data lake
Notion replaced slow warehouse syncs with a CDC pipeline (Debezium to Kafka to Hudi on S3) processed with Spark.