ClickHouse explores Rust inside a massive C++ codebase

ClickHouse is showing the version of Rust adoption that survives contact with a giant C++ server: not a rewrite, just one carefully fenced-off foothold at a time. The database spans roughly 1.5 million lines of mostly C++, runs tens of millions of automated tests every day, and still has to keep its build reproducible and FIPS-friendly. That is the real story here: Rust only gets in if it can live inside the same operational discipline as everything else.

Why this conversation matters

The people framing that discussion are the right ones. Alexey Milovidov, ClickHouse’s creator and CTO, brings the performance-first instincts that shaped the system from the start. Austin Bonander, a senior software engineer at ClickHouse and a maintainer of sqlx, brings the other half of the picture: what Rust feels like when it is not a greenfield toy, but a language that has to fit into an established database codebase.

That combination makes the lesson more useful than a typical Rust evangelism talk. The hard question is not whether Rust is elegant. It is whether Rust can be introduced without breaking the build, the release process, or the trust of teams who already have a working C++ machine that moves a lot of data and cannot afford drama.

A giant C++ system does not invite rewrites

ClickHouse’s own history makes the incremental approach feel less like caution and more like common sense. The project began in 2009, went open source on June 15, 2016, and by June 15, 2026 the company was marking ten years in open source with more than 2,000 contributors. It was originally built for Yandex.Metrica, a system that now processes more than 20 billion events daily and stores more than 13 trillion records.

That scale is exactly why “just rewrite it” is not a serious plan. When a database has that much history, the rational move is to look for narrow, well-bounded places where Rust can earn its keep. You are not trying to replace the whole machine. You are trying to prove that one component, one library, or one subsystem gets safer or easier to maintain in Rust without upsetting the rest.

Where ClickHouse started

The first Rust integration tells you a lot about the strategy. ClickHouse’s initial Rust foothold was BLAKE3, which is a smart place to begin because hashing is self-contained, performance-sensitive, and easy to isolate from the rest of the server. That kind of workload gives you a clear boundary: if the Rust piece works, you get a clean win; if it misbehaves, the blast radius stays small.

ClickHouse then wired Rust into its CMake build using Corrosion and added a dedicated `/rust` directory to the tree. That matters more than it sounds. Once Rust has a proper home in the build system, the language stops being an exception and starts being another dependency with rules, paths, and ownership. For a mixed-language shop, that is usually the first real milestone.

There is also a very practical guardrail in the build behavior: Rust is an optional dependency, and if Rust is missing, some features are simply omitted from compilation. That is the kind of compromise mature infrastructure teams understand immediately. The build keeps moving, the system stays reproducible, and Rust earns its place by improving specific parts of the product rather than holding the whole release hostage.

The real debate is language plus ecosystem

One of the strongest threads in the discussion is that the hardest part may not be Rust the language. It may be Rust the ecosystem, especially when it has to coexist with an established C++ server, a carefully managed CMake build, and supply-chain expectations that are stricter than what many application teams deal with.

That is where the compliance angle becomes important. ClickHouse Government advertises FIPS 140-3 support, which is a reminder that some customers care as much about approved cryptography, reproducible builds, and vendor control as they do about raw throughput. ClickHouse also documents vendoring to control exactly what gets installed, which is the sort of detail that often decides whether a Rust experiment stays in a lab or makes it into production.

For teams in the same boat, the takeaway is simple: the adoption question is not just “Can we write this in Rust?” It is “Can we ship this under our existing rules without creating a second, looser process on the side?”

What the Rust client says about the next step

ClickHouse is not only using Rust internally. It also has an official Rust client that uses serde and RowBinary over HTTP, with plans to move to Native over TCP. That tells you the Rust story is spreading from internal implementation work into the outer edges of the product, where users feel it directly.

The client choice is useful as a guide for your own stack. HTTP plus RowBinary is a practical on-ramp because it keeps the integration simple and familiar. Native over TCP is the next-level move once the team wants tighter protocol efficiency and more direct interaction with ClickHouse’s own wire format. In other words, start with the path that is easy to ship, then move closer to the metal once the Rust pieces have earned trust.

What mixed-language teams should copy

If you are working in a large C++ codebase, the ClickHouse pattern is the one worth stealing:

• Start with a narrow, self-contained workload, like hashing or another leaf component.

• Put Rust into the real build system, not a sidecar process that only works on a good day.

• Keep Rust optional at first so missing toolchain pieces do not break the whole product.

• Treat compliance and vendoring as part of the design, not paperwork you handle later.

• Measure success by whether the new code survives the same tests, release rules, and operational constraints as the old code.

That is why this ClickHouse story lands so well for Rust developers. It is not selling the fantasy of a clean slate. It is showing the messier, more believable path: Rust slipping into a giant C++ system through one proven component, one build hook, and one compliance boundary at a time.