ClickHouse fsync: What the History Tells Us

When engineers work with databases like MySQL or PostgreSQL, durability is often taken for granted. It’s natural to expect that every committed write is safely persisted to disk.

However, that assumption doesn’t always carry over to specialized analytical databases like ClickHouse.

One pattern we’ve repeatedly seen while operating ClickHouse as a data platform team is application teams requesting fsync support to achieve stronger durability guarantees. While the request is understandable, it reflects an expectation inherited from OLTP databases rather than one aligned with ClickHouse's architecture.

Although fsync exists in ClickHouse today, it was never part of its original design philosophy. Understanding its history explains why we generally do not recommend enabling it.

ClickHouse Was Never Designed Around fsync

ClickHouse development started in 2009 and was open sourced in 2016, yet fsync support only arrived in 2020 through GitHub issue #10286.

The feature was introduced to mitigate a small set of storage failures, primarily:

• RAID write holes
• Non-atomic sector updates on HDDs

Even the maintainers acknowledged that fsync offers no protection against filesystem bugs that suppress errors or silent data corruption.

In other words, fsync was never intended to provide comprehensive durability guarantees—it addresses only a narrow class of failures.

More importantly, ClickHouse successfully operated for over a decade without it. Its durability model has always relied on replication and distributed architecture, not synchronous disk flushes.

fsync Solved a Specific Problem

The original implementation was driven by requirements from Yandex Cloud and landed as an experimental feature in 2020.

It was added to satisfy a particular use case, not as a foundational component of ClickHouse’s storage engine.

That distinction matters because many users assume fsync is central to ClickHouse durability when, historically, it has been an optional add-on.

A Feature with a Long History of Fixes

Since its introduction, fsync has required multiple rounds of bug fixes across 2021(#21642, #18845), 2022(#38993,#34739) and 2023(#44781), with durability-related improvements continuing even into 2026(#104137) suggesting meaningful gaps in fsync implementation exists even today.

For a mechanism sitting on the critical durability path, this history is notable.

Durability features should be among the most mature and battle-tested parts of a database. Instead, fsync in ClickHouse has evolved through years of iterative fixes, suggesting it remains an area of active refinement rather than a fully mature subsystem.

Even the ClickHouse Maintainers Didn’t Use It

Perhaps the strongest evidence comes from the ClickHouse maintainers themselves.

During discussions around fsync, they explicitly stated that Yandex production services did not enable it, relying instead on geographically distributed replication and quorum inserts.(#21642)

This reflects ClickHouse’s original philosophy: durability should come from replication rather than forcing synchronous writes to disk.

Another discussion in 2022 noted that virtually nobody was using the feature.(#34739)

Also, most fsync-related issues fixed between 2021 and 2023 were identified by ClickHouse core maintainers rather than production users, suggesting limited real-world adoption. Widely used database features typically generate extensive operational feedback, bug reports, and edge cases from the broader community.

Low Adoption Creates Operational Risk

The biggest concern with enabling fsync isn't its performance cost—it's the fact that it exercises relatively uncommon code paths.

Low-traffic code paths are inherently riskier:

• Bugs surface later.
• Edge cases remain undiscovered.
• Regressions survive testing longer.
• Operational experience is limited.

For on-premises deployments, these risks become even more significant. Diagnosing and reproducing issues can be difficult, making recovery slower and more expensive.

Durability Is Harder Than It Looks

Implementing durable storage correctly is one of the hardest problems in database engineering.

Even PostgreSQL — a system built around transactional durability — has experienced long-standing fsync issues that took years to identify and resolve.(Refer here)

If a database designed around durability can struggle with these semantics, it’s reasonable to apply extra scrutiny to a feature that was introduced much later into ClickHouse and has seen comparatively limited adoption.

Replication Remains the Right Durability Model

The evidence consistently points toward the durability strategy ClickHouse was designed around:

• Multiple replicas
• Quorum inserts
• Distributed architectures

These mechanisms are heavily exercised in production and form the foundation of ClickHouse’s reliability story.

By contrast, fsync addresses only a narrow class of storage failures while introducing less-tested execution paths and a history of implementation issues.

Final Recommendation

Based on its design history, implementation maturity, maintenance record, and guidance from ClickHouse maintainers themselves, our recommendation is straightforward:

Do not enable fsync in on-premises ClickHouse clusters.

The feature provides limited additional protection while exposing deployments to less mature code paths with uncertain operational characteristics.

For large-scale ClickHouse deployments, invest in the mechanisms the database was built around: replication, quorum inserts, and resilient distributed architectures. Those are the durability guarantees that have been trusted in production for years.