# Cloudflare cuts 1.1.1.1 cache memory by about 100 terabytes

> Five Rust data-layout changes reduce Big Pineapple’s per-entry footprint by 56% while improving measured cache insertion and lookup performance.

Canonical URL: https://www.devobs.io/news/news-cloudflare-dns-cache-memory-optimization/
By: Amara Okafor
Published: 2026-09-06T11:58:54.641Z
Updated: 2026-09-06T11:58:54.641Z
Event date: 2026-08-27
Section: Infrastructure

Cloudflare reported on August 27 that five Rust data-layout changes cut the aggregate working-set memory of its Big Pineapple DNS cache fleet by roughly 100 terabytes. The [engineering post](https://blog.cloudflare.com/dns-cache-memory-optimization-1111/) says Big Pineapple supports 1.1.1.1, Gateway DNS, DNS Firewall, AS112, and other services while holding more than 250 billion cache entries.

## Small fields multiplied into fleet-scale memory

Several optimizations remove capacity or allocation overhead that cached data no longer needs after insertion. Replacing growable vectors and strings with boxed slices and strings saves unused capacity fields. Other changes compact record metadata, store offsets instead of additional lists, and serialize records into a contiguous allocation using reusable scratch space.

In Cloudflare’s benchmarks, the per-entry footprint fell from 953 to 420 bytes, a 56% reduction. Production resident memory declined by 43% at the p99 and 42% at the p90 after rollout. Cloudflare also measured 43% higher insert throughput and 19% lower lookup latency, attributing the gains to fewer allocations and better locality. The rollout ran from May 18 through July 6 before the August report.

## Immutable data structures can shed growth machinery

The transferable insight is to match a stored representation to its lifecycle. A builder may need dynamic vectors, while an entry that will never change can use a compact immutable form. At hundreds of billions of objects, even one pointer-sized field deserves measurement.

Teams should compare heap allocations and whole-process resident memory, because allocator behavior and unrelated process state can narrow the production gain. They should also benchmark lookup and insertion together; compacting data is a poor trade if decoding consumes the saved capacity.

Cloudflare’s work avoided that tradeoff in its measurements and plans to use the freed memory for a larger cache, potentially reducing upstream DNS queries without increasing the fleet’s memory budget.

## Source references

- <https://blog.cloudflare.com/dns-cache-memory-optimization-1111/>
