---
title: "Introducing WalShadow: Sub-second Postgres replication to ClickHouse from physical WAL"
description: "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."
---

# Introducing WalShadow: Sub-second Postgres replication to ClickHouse from physical WAL

[Clickhouse](https://yomu.fyi/company/clickhouse) · Sep 10, 2026

**Type:** Announcement

## 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.

**Tags:** [ClickHouse](https://yomu.fyi/topic/clickhouse), [Postgres](https://yomu.fyi/topic/postgres)

- Source: [Clickhouse](https://clickhouse.com/blog/introducing-walshadow)
- Source URL: https://clickhouse.com/blog/introducing-walshadow
- Ingested by Yomu: 2026-09-10T16:02:31.006Z

[Read original post](https://clickhouse.com/blog/introducing-walshadow)