Cloudflare’s Big Pineapple platform, which powers 1.1.1.1 and other DNS services, maintains over 250 billion DNS cache entries at any given time. At that scale, even small inefficiencies multiply dramatically—wasting a single byte per entry costs more than 250 gigabytes of memory across the company’s fleet.

According to a Cloudflare blog post, five successive engineering changes to how cache entries are stored reduced the per-entry memory footprint by more than 50%. Across the fleet, these optimizations freed approximately 100 terabytes of memory, equivalent to the RAM in 130 of Cloudflare’s Gen 13 servers. The changes also improved performance: insert throughput rose 43% and lookup latency dropped 19%.
The first optimization replaced dynamically-sized vectors (Vec
The second change consolidated three separate lists—answer, authority, and additional DNS record sections—into a single list with offsets marking section boundaries. Using 2-byte offsets instead of 8-byte pointers and length fields saved 28 bytes per entry.
A third optimization exploited a pattern in DNS responses: most cached records have an owner (domain) identical to the queried domain. Rather than storing the full owner name for every record, Cloudflare stores it only when it differs, such as in CNAME responses. Most records require no additional heap allocation for the owner field.
The fourth change addressed enum sizing in Rust. The RecordData enum, which represents different DNS record types, allocates memory for its largest variant even when storing smaller types. The post indicates this was optimized, though the full details were truncated.
Memory savings vary by location. When EDNS Client Subnet (ECS) is enabled, authoritative servers return different answers based on client networks, requiring the cache to store multiple versions of the same query. This increases both entry count and per-entry memory consumption, making these optimizations especially impactful in ECS-heavy data centers.
Key facts
- Cloudflare’s DNS cache stores over 250 billion entries at any given time
- Five optimization changes reduced per-entry memory by over 50%
- The optimizations freed approximately 100 terabytes of memory fleet-wide
- Insert throughput increased 43% and lookup latency decreased 19%
- Memory savings came without trading speed for space
