{
  "id": 6888919,
  "title": "Memory efficiency: bytes per key",
  "url": "https://urgent.news/2026/09/12/memory-efficiency-bytes-per-key",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-09-12T07:51:33.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/sunnysahijwani/memory-efficiency-bytes-per-key-2aba"
  },
  "original_language": "en",
  "account": "In part 5 of this series, the focus is on memory efficiency, specifically the bytes per key. Regardless of whether it's executed on a laptop or 48 bare-metal cores, the memory footprint remains consistent. To measure this, 1,000,000 keys with 100-byte values were loaded into each engine, and then the memory usage was calculated by subtracting the empty-server baseline and dividing by the key count. Engine memory usage per key was measured as follows: Dragonfly at 146.1, Redis at 165.3 (13% more), and Valkey at 168.7 (15% more).\n\nDragonfly stores the same data in approximately 12-13% less memory compared to Redis and Valkey. The source emphasizes that this result is trustworthy due to its hardware-independence and methodology-proof nature. It was obtained consistently across different hardware setups, without any pipelining, cluster routing, or client bottlenecks affecting the results. The only requirement was to subtract the empty baseline and ensure that exactly N distinct keys were loaded.\n\nThe memory efficiency advantage of Dragonfly stems from its more compact internal data structures. For a 100-byte value, around 46-69 bytes of per-key overhead are present, with Dragonfly carrying less overhead than the others. However, there are two important caveats to consider. Firstly, the percentage of memory savings decreases as the key values grow larger. At 100 bytes, the overhead represents a significant portion of each key, while at 10 KB values, the overhead becomes negligible. Secondly, memory efficiency is most significant for workloads with many small keys, such as sessions, counters, feature flags, and rate-limit buckets. While a 13% memory savings may not be headline-grabbing, it can still make a substantial difference when scaling to larger datasets. For instance, at 256 GB, this translates to approximately 33 GB saved, representing a meaningful instance-size difference. Ultimately, while memory efficiency is an important factor, it is just one piece of the puzzle in determining the best architecture for a given use case.",
  "summary": "Part 5 of 7 · ← Latency under load · Next: Operational simplicity → Part 5. The shortest post in the series, and the least arguable number in it — because memory footprint is about data-structure design, not how hard you drive the client. It's the same on a laptop and on 48 bare-metal cores. The measurement I loaded 1,000,000 keys × 100-byte values into each engine, subtracted the empty-server…",
  "key_points": [],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}