On August 27, 2026, Cloudflare announced that it had redesigned the cache in "Big Pineapple," the infrastructure behind its public DNS service 1.1.1.1 and other products, freeing up roughly 100TB of memory headroom across its fleet. The company stripped away variable-length container slack from data that never changes once stored, and ultimately rethought how DNS records themselves are represented. Crucially, the memory savings came with no performance cost—benchmarks showed cache insertion getting 43% faster and lookup latency dropping 19%.
That said, the 100TB figure isn't physical RAM that was physically removed, nor does it represent 130 fewer servers in production. It's a reduction in the working set used by production processes, and Cloudflare plans to redirect the freed space toward expanding cache capacity. The results show how, at massive scale, a few bytes saved in a data structure can translate into meaningful headroom in infrastructure capacity—and how the way that data is laid out can even affect CPU wait times.
How 250 Billion Entries Turn One Byte Into 250GB
Big Pineapple powers not just 1.1.1.1 but also services including Gateway DNS, DNS Firewall, and AS112, holding more than 250 billion DNS cache entries at any given moment. Even a single wasted byte per entry adds up to over 250GB across the fleet. Slack that would be negligible in a typical application becomes a significant chunk of server memory at this scale.
Each cache entry pairs a key—containing the query name and record type—with a value containing the DNS response. The value includes the answer, authority, and additional sections, plus metadata like creation time, TTL, and hit count. Where EDNS Client Subnet (ECS) is used, authoritative servers tailor responses based on the querying network, requiring multiple versions of the same query to be cached. Locations with heavy ECS usage see both entry counts and per-entry memory footprint balloon.
To measure the impact, Cloudflare built a synthetic benchmark approximating production traffic. Record types were distributed as 56% A, 25% AAAA, and 19% TXT, with each entry holding one to four records. TXT records stood in for other variable-length record types, ranging from 64 to 224 bytes. A custom allocator tracked memory allocation, while production deployments were monitored for resident memory per instance. The distinction between benchmark results and production observations matters for interpreting the final numbers correctly.
Vec Was Too Big for Data That Never Grows Again
The first change replaced Rust's Vec<T> and String types with Box<[T]> and Box<str>. A Vec carries a pointer, a current length, and a capacity for future growth. But DNS responses never change in size once they enter the cache. On 64-bit systems, that unused capacity field wastes 8 bytes per instance, and over-allocated heap space also lingers unused.
Removing the capacity field from the eight Vec or String instances in each entry cut 64 bytes just from the struct itself. Eliminating the excess heap allocation as well, the combined savings across more than 250 billion entries exceeded 15TB. This wasn't achieved through any special compression technique—it came from aligning the type's assumption of future growth with the reality that the data is immutable once stored.
Next, Cloudflare eliminated the three separate lists for answer, authority, and additional sections, consolidating them into a single list with offsets marking section boundaries. The two removed lists each required an 8-byte pointer and an 8-byte length. Replacing them with two 2-byte u16 offsets cut 28 bytes per entry. Several boolean flags were also packed into bitflags, further shrinking the padding Rust inserts to maintain alignment.
The third change omitted the owner—the domain name a record belongs to—from most DNS records. Since the owner typically matches the query name, it can be reconstructed from the cache key. The full owner name is now retained only for cases where the name differs, such as an A record following a CNAME chain, reducing both redundant names and heap allocations.
DNS's wire format also avoids duplicating names. RFC 1035 defines a compression scheme that references domain names already appearing earlier in a message using a 2-octet pointer. However, following a compression pointer on every reference adds work to the hot path, so Big Pineapple had previously prioritized speed by storing the full owner name with every record. This change safely eliminated the redundancy by relying on the fact that the cache key is always available.
From Boxed Enums to the Wire Format
An even larger source of slack was hiding in the Rust enum used to hold DNS record types. RecordData handles data of wildly different sizes across variants—from A and AAAA up to NAPTR—but the overall width of an enum is dictated by its largest variant. In Cloudflare's implementation, NAPTR data alone took 136 bytes, making the enum's total size, including tag and padding, 144 bytes. A records need only 4 bytes, and AAAA just 16. Since these two types account for over 80% of traffic, most records were carrying around substantial unused space.
Cloudflare first moved the larger variants into a Box. This alone cut 120 bytes per record for A and AAAA entries. But boxing more data means more heap allocations, scattering data across memory. In jemalloc, which Big Pineapple uses, a 32-byte TXT record fits neatly into a 32-byte size class, but a 40-byte MX record gets rounded up to 48 bytes, wasting 8 bytes. The CPU also has to chase down a different memory location every time it reads a record.
So the fifth change stored only the record data—not the complete DNS response—in wire format, the same format used during transmission. Each record is converted into a 2-byte length plus raw bytes, and all records are packed contiguously into a single Box<[u8]>. This eliminated both the 144-byte-wide enum and the per-variant allocations, letting the CPU read nearby data in bulk.
This intermediate approach also brings runtime benefits. For A, AAAA, TXT, and DNSSEC records, the already-encoded bytes can be copied directly when constructing a response. Types containing domain names—such as CNAME, NS, and MX—still require parsing for name compression, but the scope is now narrower. This change alone cut lookup latency by 5%.
On the insertion side, the working buffer used for serialization is no longer discarded per entry but reused across processing runs. Once a record has been written and its final size determined, a single Box<[u8]> of the exact required size is allocated and the data copied in. Consolidating what were previously separate per-record allocations into one boosted insertion throughput by 13% on its own.
From 953 Bytes to 420: A 42–43% Cut in Production
Taken together, the five changes reduced net memory per entry in the synthetic benchmark from 953 bytes to 420 bytes—a reduction of 533 bytes, or 56%. Per-entry allocation volume dropped 58%, from 1.1KB to 461 bytes. Insertion performance rose 43%, from 625,000 entries per second to 893,000, while lookup latency fell 19%, from 828ns to 670ns.
Production rollout began on May 18, 2026, and finished across all target services by July 6. Because freshly restarted instances start with an empty cache, the resulting graphs show a temporary memory dip. Comparing the stable levels once caches were fully populated, Cloudflare reported p99 resident memory falling 43%, from 9.3GB to 5.3GB, and p90 falling 42%, from 6.5GB to 3.8GB. The combined difference in working set across the entire fleet came to roughly 100TB.
The benchmark's 56% figure and production's 42–43% aren't remeasurements of the same thing. The former measures cache entries under a specified record distribution, while the latter measures entire processes, including non-cache data. Traffic composition, cache occupancy, and allocator state all vary between the two. This is why multiplying 250 billion entries by 533 bytes doesn't directly yield the production figure of 100TB.
Cloudflare compared the 100TB figure to the RAM capacity of 130 Gen 13 servers. Since each Gen 13 server carries 768GB, 130 units would total 99,840GB. However, this is purely a capacity comparison—the company hasn't disclosed absolute fleet counts, decommissioned hardware, power savings, or cost impact.
What Happens to the Freed 100TB?
Rather than simply reclaiming the freed space, Cloudflare says it plans to use it to increase the maximum number of DNS cache entries. Big Pineapple uses an ARC eviction policy that gradually removes less-popular entries, and routes queries for the same registered domain to specific nodes within a data center via consistent hashing. According to the company's past explanations, cache hits can be served in under 1ms, while misses can take hundreds of milliseconds. With more capacity to retain valid entries longer, both user-facing latency and query volume sent to upstream authoritative servers could decrease.
However, that benefit hasn't yet been demonstrated with numbers. Cloudflare hasn't published before-and-after hit rates, upstream query volumes, or end-user DNS response times. The 828ns-to-670ns figure is itself a benchmark measurement of the cache lookup process—it doesn't mean end-user response times uniformly improved by 19%.
Whether this redesign ultimately translates into better service quality will depend on how much the added capacity boosts hit rates, and whether it can curb upstream queries even under conditions like ECS that multiply the number of cached versions. If those numbers surface in a future report, the 100TB of freed headroom will have evolved from a memory-savings achievement into a resource actively reducing latency and load across the DNS system as a whole.