Cloudflare saves 100 TB of memory by rebuilding the 1.1.1.1 DNS cache

Cloudflare says it freed roughly 100 terabytes of memory across its DNS infrastructure by changing how the 1.1.1.1 cache represents entries. The result did not come from a spectacular new algorithm. It came from five successive Rust changes: fewer allocations, better-sized integer types and a more compact memory layout.

The short answer

Cloudflare measured a 56% footprint reduction, 43% higher insertion throughput and 19% lower lookup latency. These numbers describe its own workload and should not be treated as a generic Rust performance promise.

At 250 billion entries, one byte becomes capacity

The Big Pineapple platform powers 1.1.1.1, Gateway DNS and DNS Firewall among other services. It keeps more than 250 billion cache entries. At that scale, one wasted byte per entry already exceeds 250 GB across the fleet.

The first lesson is methodological: an object’s logical schema does not reveal its physical cost. Dynamic arrays, pointers, lengths and alignment add bytes that are invisible in the business model. Multiplied billions of times, those details dominate hardware budgets.

Five constrained changes instead of one rewrite

Cloudflare combined several DNS sections into one allocation and replaced selected 64-bit pointers with 16-bit offsets, which are sufficient for record counts inside a DNS response. The team also reduced cache metadata and removed separate allocations.

The most abstract structure is not always the best one. When domain bounds are known, a u16 can be more accurate than a usize. It remains safe only when decoding validates the limit and tests cover boundary values.

Why speed improved as well

Lower memory use is not just about server count. Smaller objects occupy fewer CPU cache lines, require fewer allocations and create less allocator work. Reads become more local and insertions face less contention.

Cloudflare plans to reinvest the freed memory into a larger cache. A higher hit rate then reduces upstream DNS queries, potentially improving cost, latency and resilience at the same time.

What other teams can reuse

Before compacting every structure, measure resident memory in production and build a representative benchmark. Compare theoretical size, allocation counts and CPU-cache behavior. Roll out each change separately so gains remain attributable and regressions are visible.

Compact formats also carry a cost: more specialized code, extra conversions and overflow risks. Document bounds, test extreme inputs and keep observing the system after deployment.

The 100 TB result shows that large-scale optimization often starts with data representation. A memory-safe language prevents many classes of bugs, but it cannot automatically choose the most economical structure for a particular workload.