Cloudflare published a technical account on 27 August 2026 describing five changes to Big Pineapple, the platform behind 1.1.1.1, Gateway DNS and other DNS services. The platform holds more than 250 billion cache entries at a time. By redesigning how those entries are represented in memory, Cloudflare reduced the benchmarked footprint from 953 bytes to 420 bytes per entry, lowered aggregate fleet working-set memory by roughly 100 terabytes and improved both insertion and lookup performance.
What happened
Cloudflare replaced growable vectors and strings with fixed-size boxed slices and strings where cached data never changes. It combined several DNS record lists into one list with compact offsets, removed record-owner names when they could be reconstructed from the cache key, packed boolean state more tightly and changed how large enum variants were stored. Each change removed capacity fields, pointers, padding or heap allocations that were useful during construction but unnecessary after an entry entered the cache.
The company tested the work with a synthetic traffic mix modelled on production and a custom allocator that counted allocation size and frequency. It then compared those benchmarks with resident-memory measurements during the production rollout. Across the five changes, per-entry allocation fell from 1.1 KB to 461 bytes. Insert throughput rose from 625,000 to 893,000 entries per second, while lookup latency fell from 828 to 670 nanoseconds.
Why it matters
This is not simply a Rust optimisation story. It shows how a harmless-looking abstraction becomes an infrastructure decision when multiplied across a very large workload. One unused eight-byte field is trivial in a normal application; across 250 billion records it represents terabytes of memory, additional allocator work and poorer cache locality.
The result also challenges the assumption that resource savings must trade away speed. Removing allocations and keeping related data closer together improved memory efficiency and hot-path performance at the same time. Cloudflare plans to reinvest the freed capacity into a larger DNS cache, which can raise hit rates and reduce queries sent to upstream authoritative servers.
The practical implication
Engineering teams should profile the data structures that dominate their real workload before scaling infrastructure around them. Look for objects that become immutable after creation, collections that retain spare capacity, repeated values that can be inferred from existing context and representations sized for rare cases. The goal is not clever compression everywhere; it is removing flexibility the running system no longer needs.
Optimisation must stay evidence-led. Build a representative benchmark, measure allocations as well as total memory, track latency and throughput together, and confirm the result with production telemetry during a staged rollout. A smaller structure is only an improvement when correctness and operational performance remain visible.
Key takeaways
At high volume, bytes per record and allocations per request are infrastructure metrics.
Use immutable representations when production data no longer needs spare capacity or mutation.
Validate memory savings against latency, throughput and production resident memory—not a microbenchmark alone.
Sources
This article is original analysis written by IT Web Builder. The reporting and product details below were used as references and are credited to their publishers.
Cloudflare EngineeringHow we saved 100 terabytes of memory by optimizing 1.1.1.1's DNS cache — published 27 August 2026↗IT Web Builder publishes original summaries and practical commentary. We do not reproduce source articles. Product claims and announcements are linked to their original publishers so readers can verify the details.