ClickHouse Managed Postgres: Direct I/O wal-g backups that spare the page cache

ClickHouse Engineering on October 2, 2026 explains why ClickHouse Managed Postgres uses Direct I/O for live base backups (blog, Kaushik Iska). The lead is Managed Postgres + wal-g backup I/O—not a ClickHouse analytics-engine product launch.

The problem Direct I/O targets

Base backups that share local NVMe with live queries can thrash the Linux page cache: one-shot backup reads pull cold pages through the cache and push out warm Postgres pages queries still need. ClickHouse configures wal-g with WALG_DIRECT_IO=true so those reads use O_DIRECT and skip the page cache, leaving warm OS-cache pages alone during the backup.

Stripe-sized reads on RAID0

On multi-NVMe RAID0, Direct I/O also disables readahead, which can cut array throughput. ClickHouse’s answer: size each direct read to span the whole RAID0 stripe (WALG_DIRECT_IO_BLOCK_COUNT scaled with drive count—e.g. four drives → 4 MiB reads) and scale disk-reader concurrency with the hardware (dense NVMe families can use full vCPU count). Config lands in /etc/postgresql/wal-g.env. ClickHouse says every Managed Postgres server ships with this path by default on the new machine image—vendor claim, attributed.

Object storage still holds base backups plus archived WAL for PITR; the Direct I/O story is the local NVMe hot path into wal-g.

Vendor benches (attribute only)

All figures below are ClickHouse-attributed on stated hardware (including an i8ge.12xlarge / four-NVMe / 467 GB pgbench setup)—not independent newsroom measurements:

• Query latency hit during backup cut by about two thirds vs buffered
• Buffered arm evicted 40 GiB of a warm idle table; Direct I/O arms evicted 0 GiB
• Production knobs finished in 71 seconds on that 467 GB database
• About 14% less CPU called out in the short version

Treat those as engineering evidence from the post, not ATN reproduction.

What’s next (not GA)

ClickHouse says it is prototyping incremental backups—roadmap language only. That is not shipped incremental-backup GA.

Who should care

Operators on ClickHouse Managed Postgres, or anyone running wal-g base backups on shared local NVMe, should read the engineering post for the Direct I/O + stripe-sizing rationale. Confirm defaults and escape hatches against current Managed Postgres docs before changing self-managed wal-g knobs to match.