ClickhouseAnnouncement
Introducing WalShadow: Sub-second Postgres replication to ClickHouse from physical WAL
Summary
ClickHouse announces WalShadow, an open-source engine that replicates Postgres data to ClickHouse directly from physical WAL, targeting sub-second analytical availability without logical replication. It consumes the physical WAL stream outside the source database, tracks schema in a shadow Postgres instance, decodes heap records through parallel Rust-based decoders, builds ClickHouse-native blocks, and inserts them concurrently. Because parallel blocks can arrive out of order, each row carries the source WAL position (_lsn), while barriers preserve ordering for schema changes and truncations. In benchmarks using modest c8i.2xlarge instances, WalShadow reached approximately 200 ms commit-to-visible latency and 289,000 rows per second, compared with PeerDB’s roughly 10 seconds and 120,000 rows per second; it supports initial load, continuous replication, schema evolution, restart recovery, and planned switchovers.
Context
Traditional Postgres-to-ClickHouse CDC systems use logical replication, which the post says carries operational overhead and consumes source resources. Most managed Postgres services do not expose physical WAL, preventing this architecture, while ClickHouse Managed Postgres controls both sides of the stack and can integrate WalShadow into the Postgres replication layer.
Approach / What changed
WalShadow consumes the physical WAL stream used for Postgres replication and recovery. It replays catalog WAL into a schema-only shadow Postgres instance, distributes heap records across Rust-based decoders, groups rows into ClickHouse-native blocks, and inserts those blocks through a separate parallel pool. It uses each row’s _lsn to handle out-of-order arrival and adds barriers for ordered operations such as schema changes and truncations.
Takeaways
WalShadow avoids logical replication slots, Kafka, JSON serialization, and a separate normalization step; the source only ships physical WAL, with a load profile described as similar to a physical standby.
The replication lifecycle includes initial load, continuous replication, schema evolution, restart recovery, and planned source switchovers. Supported schema changes include ADD COLUMN, RENAME COLUMN, DROP COLUMN, and CREATE TABLE.
In the stated benchmark, WalShadow delivered approximately 200 ms commit-to-visible latency and 289,000 rows per second, versus PeerDB’s roughly 10 seconds and 120,000 rows per second.
Source and freshness
- Source
- clickhouse.com
- Published
- Added to Yomu
Summaries are generated from the original by a language model. Check the original before relying on it.
Keep reading
Related reading
The Good Stuff
Paid picks we use ourselves. Links carry a referral code — a subscription through one earns us a commission at no extra cost to you.
The best engineering reads, once a week
One useful email. Unsubscribe anytime.