Cloudflare announced the results of a series of low-level improvements to the DNS store in the Big Pineapple platform, which powers 1.1.1.1, Gateway DNS, DNS Firewall, AS112, and several other DNS services. The platform stores more than 250 billion DNS entries at any given time, so eliminating one byte per entry saves more than 250 gigabytes of memory across the fleet.
Five successive changes to the Rust-written data structure reduced the size of each entry from 953 bytes to 420 bytes, a reduction of 56%. After the changes were rolled out, the working-set memory used across Cloudflare’s fleet decreased by approximately 100 terabytes, while performance improved rather than being sacrificed: entry insertion speed increased by 43%, and store lookup latency decreased by 19%.
Why did DNS entry size matter?
Big Pineapple starts with an empty store at startup, then fills as queries arrive until it reaches its maximum capacity, at which point the oldest or least-used entries are removed. Store size varies between data centers, and the use of EDNS Client Subnet can result in multiple answers being stored for the same query, because authoritative servers may provide different answers depending on the client’s network.
Each entry consists of a key that identifies the domain name, record type, and certain attributes, and a value containing the DNS answer, authority and additional sections, and metadata such as creation time, usage count, and TTL duration. At this scale, extra fields or reserved space are no longer minor internal details, but become a massive operational cost.
Where did the savings come from?
Cloudflare replaced growable Vec and String structures with fixed structures, Box<[T]> and Box<str>, after storing the response, because the data is not modified afterward. This change removed the capacity field maintained by growable structures and also limited unused reserved space. Since each entry contains eight fields of this type, the saving amounted to 64 bytes per entry, and more than 15 terabytes across the entire store.
The answer, authority, and additional section lists were also combined into a single list, using u16 offsets instead of larger pointers and lengths. This saved 28 bytes per entry. The structure also benefited from compressing several Boolean fields into a single bitflag, reducing wasted space caused by the memory alignment Rust imposes within structures.
In most DNS records, the record owner matches the domain that was queried. Cloudflare therefore no longer stores the complete owner name in these cases, instead reconstructing it from the storage key when building the answer. When the name differs, as with CNAME records, the complete name is stored. This eliminated memory allocations for most owner names while retaining the cases that actually require the name.
Reducing the cost of large record types
The RecordData structure used an enum whose size equaled that of the largest record type, NAPTR, at 144 bytes after accounting for the tag and alignment. As a result, A records requiring only 4 bytes and AAAA records requiring 16 bytes occupied much more space than necessary, even though A and AAAA represented more than 80% of the test traffic.
Putting the large types inside a separate Box was tested. This reduced waste for A and AAAA records, but added separate allocations and memory-locality issues. The final solution was to store the record data itself as contiguous raw bytes inside Box<[u8]>, with a two-byte length prefix for each record. This removed the enum and multiple-allocation overhead and improved the processor’s use of the storage cache.
This choice means that records are no longer randomly indexable and must instead be traversed sequentially. Cloudflare considers the cost limited because the number of records in each entry is small. Most types, including A, AAAA, TXT, and DNSSEC records, can also be copied directly into the outgoing DNS message, while types containing domain names, such as CNAME, NS, MX, and SOA, still require parsing to apply DNS name compression.
What changed in practice?
Production measurements showed a decrease in resident memory at the 99th percentile from 9.3 to 5.3 gigabytes, or 43%, and from 6.5 to 3.8 gigabytes at the 90th percentile, or 42%. Allocations per entry decreased from 1.1 kilobytes to 461 bytes, while insertion speed increased from 625,000 entries per second to 893,000, and lookup latency fell from 828 nanoseconds to 670 nanoseconds.
The rollout of the changes began on May 18, 2026, and was completed across all services on July 6, 2026. Cloudflare explains that production resident memory includes other data in addition to the store, so the actual reduction at the process level was lower than the result of the isolated per-entry measurement. The company also plans to reinvest the freed memory in increasing store capacity without increasing memory consumption, with the goal of improving cache hit rates and reducing queries sent to upstream servers.
The importance of this case lies in showing that data-structure improvements, such as removing unnecessary capacity, consolidating allocations, and improving locality, can have a greater impact than directly adding hardware resources when a service operates on hundreds of billions of items. However, some trade-offs remain: raw storage increases the complexity of handling records, retrieving the storage key becomes necessary to reconstruct owner names, and test results depend on a specific traffic mix that does not fully match production. Therefore, production measurements, not theoretical figures alone, remain the most important reference when evaluating improvements of this kind.