ClickHouse says it changed how backups read data in its managed PostgreSQL service, helping a live database keep recently used data in memory while a backup runs. In a test on a 467GB database, its Direct I/O setup avoided evicting a 40GiB warm table and completed the backup in 71 seconds.
ClickHouse Watch analysis
What happened
A conventional buffered backup sends data through Linux’s page cache. ClickHouse says that can push out data the database may need again, as well as use CPU to copy bytes through the kernel. Direct I/O bypasses that cache, but brings a trade-off: it also disables the kernel’s read-ahead, which can leave drives in a striped array underused if reads are too small.
ClickHouse says it tuned read sizes to span the RAID0 array and adjusted the number of parallel readers to the hardware. In its test, buffered reads evicted all 40GiB of a table that had been warm in memory. The Direct I/O backup evicted none and finished in 71 seconds. The company also reports that the tuned approach cut the latency hit during backup by about two-thirds and used about 14% less CPU than buffered reads. Read ClickHouse’s Direct I/O account.
Why it matters
Backups are supposed to protect a database, not make its next query hunt for data the backup has just displaced. This account shows why simply switching on Direct I/O may not be enough: the read size and concurrency need to suit the storage layout. The figures are from ClickHouse’s test setup, not a promise that every database will see the same result.
Our read
The useful lesson is less “Direct I/O fixes backups” than “measure the backup alongside the workload it shares drives with”. ClickHouse’s approach is a practical engineering case study, especially for operators using striped NVMe. If you run backups on the same storage as live database traffic, compare cache eviction, query latency and CPU use, rather than judging the job by whether it completed successfully. A green tick in the backup log can conceal a rather less green morning for everyone else.
What to watch
- Whether ClickHouse publishes comparable results across other storage layouts and workloads.
- How query latency changes under sustained live traffic, not only in this test.
- Whether the service’s hardware-aware configuration remains effective as database size and drive count grow.
Discussion spark: Should database backups prioritise protecting live-query performance, even if that means tuning backup reads to each machine’s storage layout, or is a simpler standard configuration worth the trade-off?
Sources and evidence
- Source update (2 October 2026, 13:27 UTC)
not affiliated with or endorsed by ClickHouse