Cloudflare cut the memory footprint of every entry in its DNS cache by 56%, and because that cache holds over 250 billion entries at any given moment, the change frees roughly 100 terabytes of RAM across the company's entire fleet, the equivalent of about 130 of its current-generation servers. The savings came from a months-long rewrite of the internal data structures behind Big Pineapple, the Rust-based recursive resolver that has powered 1.1.1.1 since 2023, and none of it required new hardware or a change to the DNS protocol itself. It is, in plain terms, a story about a team finding waste that had been sitting in plain sight since the system was first designed.

  • Per-entry memory dropped from 953 bytes to 420 bytes, and per-entry heap allocations fell from about 1.1KB to 461 bytes.
  • Cache insert throughput rose 43% (625,000 to 893,000 entries per second); lookup latency improved 19% (828ns to 670ns).
  • The fleet-wide rollout ran gradually from May 18 to July 6, 2026, with no observed regression in resolver correctness.
  • The resolver, internally called Big Pineapple, also serves Gateway DNS, DNS Firewall and AS112, not just 1.1.1.1.

What did Cloudflare actually change?

Nothing about how DNS works. Every optimization here is about how a cached DNS answer sits in memory between the moment it arrives from an authoritative server and the moment it gets served back out. A cache entry used to be built the way most engineers would build it without thinking twice: a Vec<T> for the list of records, a String for the owner name, separate collections for the answer, authority and additional sections, and an enum to represent whatever record type showed up. Convenient to write. Expensive to store 250 billion times over.

RelatedIran’s Internet Flickers Back On After a 3-Month Blackout

ChangeWhat it removesWhere the bytes went
Vec/String → Box<[T]>/Box<str>the unused growth capacity every Vec reserves~64 bytes/entry
Merged record sectionsthree separate pointer-based lists~28 bytes/entry, via one list + u16 offsets
Owner-name dedupredundant copies of the queried domainstored only when it differs from the query
Boxed enum variantspadding forced by the largest variantsmaller struct for the dominant A/AAAA types
Raw wire-format storageparsed, pointer-heavy record representationsone contiguous byte buffer per entry

The pattern across all five changes is the same: a Vec<T> reserves room to grow that a finished, immutable cache entry will never use, and a Rust enum has to be as large as its biggest variant even when 95% of entries are the small, boring case. Once Cloudflare's engineers replaced growable containers with fixed-size ones and moved the rare large variants onto the heap, the entry shrank from something built for flexibility into something built purely for sitting in RAM.

DNS cache entry size before and after the rewrite Per-entry memory footprint fell from 953 bytes to 420 bytes, and per-entry heap allocations fell from about 1127 bytes to 461 bytes. Per-entry footprint 953B 420B before after Per-entry allocations 1.1KB 461B before after genztech.blog
Fig 1 · benchmark Shrinking a single cache entry from 953 to 420 bytes sounds small until you multiply it by the roughly 250 billion entries Big Pineapple holds at any moment, which is where the 100TB figure comes from.

Why does one byte per entry matter this much?

Because Big Pineapple isn't caching a few million things. Cloudflare's own framing in the post is the sharpest way to say it: wasting a single byte per cache entry costs more than 250 gigabytes of memory across the fleet. At 250 billion entries, small design decisions stop being rounding errors and start being capacity-planning line items. This is also why the throughput and latency gains matter as much as the raw memory number. A smaller entry means more of the cache fits in a CPU's cache lines and TLB reach, not just in RAM, which is the likely reason insert throughput jumped 43% and lookups got 19% faster almost as a side effect of shrinking the struct, not from any change to the lookup algorithm itself.

Is this the first time Cloudflare has rebuilt this stack?

  1. Apr 2017"How we made our DNS stack 3x faster." Cloudflare's earlier DNS stack, then written in Go, cut record storage roughly 9x by switching from JSON/protobuf to MessagePack.
  2. Feb 2023Big Pineapple replaces the Knot Resolver-based architecture. A new Rust and Wasm resolver becomes the foundation for 1.1.1.1, Gateway DNS, DNS Firewall and 1.1.1.1 for Families.
  3. May 18 – Jul 6, 2026The memory rewrite rolls out fleet-wide. Five structural changes to the cache entry ship gradually across production with no correctness regressions reported.
  4. Aug 27, 2026Cloudflare publishes the engineering writeup. Full before/after numbers, plus the specific Rust patterns used, made public.

So no, this is Cloudflare's third public pass at squeezing its DNS storage layer, and the pattern across all three is consistent: whichever language and format they're using at the time, DNS-record storage keeps turning out to carry more overhead than anyone assumed until someone measures it. The 2017 post solved a serialization-format problem. This one solves an in-memory data-structure problem in the Rust codebase that replaced it. Neither fix depended on the other, which suggests there is no shortage of similar waste left to find in systems that store the same shape of record a quarter-trillion times over.

RelatedGoogle Paid $10M for Spirit Airlines' Emails and Chats

What does this mean for Cloudflare's business, and for everyone else running Rust at scale?

For Cloudflare, 100TB of freed memory is capacity it does not have to buy, cool or rack, which is a direct, if unglamorous, margin story for a company (NYSE: NET) that runs one of the largest server fleets in the industry on relatively thin hardware margins. It's also a data point for any infrastructure team running Rust in production: none of the five techniques here are exotic. Box<[T]> instead of Vec<T> once a collection is finalized, boxing oversized enum variants, and storing wire formats as raw bytes instead of parsed structures are all patterns available in stable Rust today, not research ideas. The interesting part isn't that Cloudflare found a clever trick; it's that a system serving trillions of queries a day had been running with 56% more memory per entry than it needed, for years, before anyone went looking.

Our take

This is a genuinely useful engineering post dressed up as a modest one. Cloudflare isn't claiming a new algorithm or a breakthrough, and the company is upfront that the gains came from unglamorous struct-layout discipline rather than anything novel. That's exactly why it's worth reading: at Big Pineapple's scale, the boring 5% of a system, how a record gets stored between requests, is worth more than most teams' headline features. Anyone maintaining a long-lived Rust cache or resolver now has a concrete checklist to run against their own hot path, and Cloudflare has quietly built a habit of publishing these numbers rather than just the win. Expect a similar deep dive the next time Big Pineapple's storage layer gets touched again, because on this evidence, Cloudflare goes looking more than once.

Primary sources

Original analysis by GenZTech. Figures current as of August 2026.