Technology1 min read

What I learned from a month with WalShadow on ClickHouse Managed Postgres

By · Published by Everything Blog

In short

WalShadow decodes physical WAL logs outside of Postgres and writes the processed records directly into ClickHouse as blocks, an approach made possible because ClickHouse manages both the source and target environments. In side-by-side benchmarking against ClickPipes, the system maintained consistent replication delays even as write rates expanded. The pipeline smoothly weathered schema modifications and operational shifts across mixed workloads without manual intervention, while developers refined its flush timeout to 200 milliseconds.

Key points

  • Direct physical log ingestion maintained nearly constant replication delays even as datab…: Direct physical log ingestion maintained nearly constant replication delays even as database write rates increased.
  • Unlike traditional interval batching that forces tradeoffs between delay and frequency, W…: Unlike traditional interval batching that forces tradeoffs between delay and frequency, WalShadow automatically sustained throughput.
  • Replication through WalShadow continued uninterrupted during operational events and schem…: Replication through WalShadow continued uninterrupted during operational events and schema updates without needing manual intervention.

Sources checked by our analysis pipeline: 1

This is a guest post from Hidehiko ASAHI, a database engineer at an IT company in Japan and an AWS Community Builder

Note: Everything in this post was tested with WalShadow in Private Preview during September and October 2026, and all numbers reflect that environment at the time. Defaults and behavior may change before general availability.

Summary

- When you analyze Postgres changes in ClickHouse, how low you can keep the replication delay is a key design consideration

- Batching writes at a fixed interval lets you trade replication delay against write frequency by tuning that interval, up to the write rate the pipe can process. Reading the WAL directly, which is possible because ClickHouse manages both sides of the stack, kept the delay nearly constant as I increased the write rate

- The application wrote only to Postgres, and replication continued through schema changes and operational events without any manual intervention. Using the destination tables comes with a few caveats that stem from how WalShadow works

- Issues I reported during the Private Preview were fixed, and I was…

Technology