How Cloudflare Reclaimed 100 Terabytes of RAM by Rethinking How 1.1.1.1 Caches DNS at the Edge

Cloudflare says it freed roughly 100 terabytes of memory across its global fleet by changing how a single component stores data in RAM. The component, called Big Pineapple, powers the company's 1.1.1.1 public resolver and several other DNS services. At any moment it holds more than 250 billion cache entries spread across data centers worldwide. Wasting even one byte per entry, the company notes, costs more than 250 gigabytes of memory fleet-wide.

The work landed in production between May 18 and July 6, 2026, and the company published the breakdown on August 27. It is a quieter kind of infrastructure story than a new data-center campus or a fresh AI chip, but it touches the same budget line. Memory is a hard cost. Every gigabyte of RAM a provider must install to keep its edge cache warm is a server, a power draw, and a line item.

A cache measured in the hundreds of billions

Big Pineapple is the engine behind 1.1.1.1, Gateway DNS, DNS Firewall, AS112, and several other Cloudflare DNS services. It runs on machines inside the company's edge locations, the same facilities that terminate web traffic close to users. The cache is what lets a resolver answer a repeat query without walking back to an authoritative server every time.

On a cold start the cache is empty. As queries arrive, it fills until it hits its maximum entry count, then it evicts older or less popular items to make room. The exact size changes from site to site. When EDNS Client Subnet is in use, authoritative servers return different answers depending on the client's network, so the resolver caches multiple versions of the same query. That both raises the entry count and inflates the memory each entry consumes.

The numbers in the post show why the per-byte math matters. Cloudflare benchmarks a cache entry before the changes at 953 bytes, and after at 420 bytes, a 56 percent drop. Per-entry allocations fell from 1.1 kilobytes to 461 bytes. Multiplied across 250 billion entries, the savings add up to about 100 terabytes of working-set memory across the fleet, which the company says equals the RAM in roughly 130 of its Gen 13 servers.

Five changes, none of them glamorous

The gains came from five separate changes to how entries are laid out in memory, all written in Rust. None required new hardware or a different network design. They were, in the company's words, a matter of not paying for things the cache no longer needed once an entry was written and frozen.

First, the team replaced Rust's growable Vec and String types with fixed-size Box<[T]> and Box<str>. A Vec carries a pointer, a length, and a capacity field; once a DNS response is cached it is never modified again, so the capacity field is dead weight, and the slack space Vec reserves for future growth goes unused. Each cache entry held eight such fields, and swapping them saved 8 bytes per field, or 64 bytes per entry, which the company says totaled more than 15 terabytes across the fleet.

Second, instead of keeping the answer, authority, and additional sections in three separate lists, the code stores one list with short offsets to where each section begins. DNS record counts fit in a 16-bit integer, so two-byte offsets replaced the eight-byte pointer and eight-byte length that each separate list required, saving 28 bytes per entry.

Third, the team packed several boolean flags into a single bitfield. This removed individual padding bytes and let the surrounding struct shrink by more than the booleans alone, because of how Rust aligns and rounds struct sizes.

Fourth, the code dropped the record owner field when it matched the queried domain. DNS lets a record's owner differ from the queried name, most often behind a CNAME, but in the majority of cases they are the same. By inferring the owner at read time from the cache key, most records needed no heap allocation for that field at all.

Fifth, and most involved, the team reworked how record data is stored. Initially each record was a Rust enum sized to its largest variant, which meant a tiny A record (4 bytes) sat inside a 144-byte slot padded out to fit a rare NAPTR record. Boxing the large variants moved their data to the heap, which saved space but scattered data across memory and added allocator overhead. The final design stores the records as a single contiguous buffer of raw bytes with a two-byte length prefix per record, copying most record types straight into the outgoing response rather than re-serializing them field by field. This tightened memory locality and cut lookup latency by about 5 percent in benchmarks; combining all five changes lifted insert throughput 43 percent and dropped lookup latency 19 percent.

Why this belongs in the edge conversation

It is easy to read a memory-optimization post as inside baseball, but the incentive structure is the same one pushing hyperscalers to build their own servers and AI labs to secure dedicated power. Every efficiency win at the edge delays or removes a capital spend. Cloudflare's resolver sits in facilities the company operates on six continents, so a 100-terabyte fleet-wide reduction is not abstract: it is RAM that does not need to be bought, cooled, or replaced.

The company says it plans to reinvest the freed memory into larger cache capacity without raising total memory usage. Bigger caches mean higher hit rates, which means fewer queries climb back to authoritative servers, which means less upstream load and faster answers for end users. That is the same flywheel that makes edge caching worth operating in the first place.

The story also lands at a moment when data-center economics are under a brighter spotlight than usual. Recent coverage has weighed the power and water footprint of AI-oriented facilities, the surge in hyperscaler capital spending, and the resilience questions raised by regional cloud outages. A resolver cache is a smaller, older kind of workload than a GPU cluster, but it runs on the same physical substrate, and the same pressure to do more with the same hardware applies.

What engineers can take from it

Cloudflare frames the post as a practical tour of Rust memory layout rather than a product announcement, and that is where its value sits. The lessons travel: a frozen-in-place data structure rarely needs a growable container; alignment padding can swallow savings you thought you had already captured; and storing already-parsed data can beat storing wire-format bytes when the hot path is reads, not writes. The team measured each change with a custom allocator wrapping Rust's system allocator, then confirmed the savings in production resident-memory figures rather than trusting the benchmark alone.

At the 99th percentile, per-instance memory fell from 9.3 gigabytes to 5.3 gigabytes. At the 90th percentile it fell from 6.5 to 3.8. Instances with fuller caches saw the largest absolute savings, which is the population that matters most at peak.

For a company whose pitch to customers rests on speed and reach at the edge, squeezing the resolver is also a competitive move. DNS is the first hop of nearly every internet request, and 1.1.1.1 is one of the most-used public resolvers on the planet. A faster cache with lower memory cost is a direct improvement to that first hop, shipped without anyone downloading an update or changing a setting.

The post closes by inviting other systems engineers to share their own optimizations, a small nod to the fact that this kind of work is cumulative. One company's 100 terabytes is another's roadmap. As edge networks keep absorbing more of the compute that used to live in centralized regions, the providers that win will often be the ones who noticed they were paying for bytes they never used.

Source: Cloudflare blog — Saving 100 terabytes of memory by optimizing 1.1.1.1's DNS cache