Build1 publisher2 min readPublished
Redis 8.10 converts hashes to the compact encoding only on HIMPORT or an RDB reload
Redis's release blog advertises up to 50% lower hash memory. One tester found that existing keys keep the old encoding until you rewrite them through HIMPORT or reload them from disk with three parameters that ship at zero.
The Engineer · Build desk
What happened
- Redis 8.10 shipped in July with compact hashes, an encoding that stores a shared set of field names once instead of once per key, advertised on the release blog as up to 50% lower memory and 2x faster hash loading.
- A test that loaded 100,000 hashes through ordinary HSET calls against one shared four-field schema found INFO stats still reporting hash_templates:0 and hash_template_keys:0.
- Two things create the encoding: the new HIMPORT command pair, or a reload from an RDB file with three new config parameters that all ship set to 0.
- With those parameters set, a BGSAVE plus a container restart folded all 100,000 existing keys into one shared template and cut used_memory by 18.8%.
- The four-field user profile came in well under the advertised 50%, while an eight-field schema of long field names against one-character values went well over it.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- cost Capturing the saving on data you already hold costs either a write-path rewrite to HIMPORT or a restart or failover of every node that stores those hashes.
- constraint A primary that stays up and never calls HIMPORT keeps the old encoding for the life of the process, so the memory win is tied to a maintenance event and not to the version you are running.
- decision Below four or five keys per fieldset the template overhead exceeds the plain hash, so anyone grouping small or sparsely shared schemas has to count keys per fieldset before turning this on.
- contradiction The blog's 2x loading figure and the measured 35% can both be true, but only for a client that spends a meaningful share of its time writing repeated field names onto the wire.
HIMPORT is two commands. `HIMPORT PREPARE u name email country last_login` declares the field list once on that connection, and `HIMPORT SET user:1 u Alice [email protected] UK 2026-07-14` then loads one key's values against the declared list [4]. According to the dev.to test, that pair is the only documented way to create a template directly [5]. The saving comes out of field names, so the share of a key's memory that is field names rather than values sets the ceiling [6].
The conversion does not happen on live data. Redis does not inspect a running hash, notice that it shares a field set with a thousand others, and fold it in [7]. The other route is a reload from an RDB file, governed by three parameters that all ship at 0: `hash-rdb-load-min-template-entries`, `hash-rdb-load-max-template-entries` and `hash-rdb-load-template-disassembly-threshold` [8]. Three zeroes is an unusual way to ship a 50% memory saving.
Set to 3, 20 and 2, the first restart converted nothing and `hash_templates` stayed at 0, which the writeup attributes to operator error [9]. After the fix, `used_memory` fell from 17,459,464 bytes to 14,182,656 on Redis 8.10.1 in Docker [10][11]. That is 3,276,808 bytes over 100,000 keys, about 33 bytes each [12]. The author reports the same proportion from the direct HIMPORT comparison on that schema [10].
The template has a fixed cost of its own, and something has to pay for it. Reading `MEMORY USAGE` on the first key while varying how many keys share a fieldset, the equivalent plain hash with the same fields reports 112 bytes, and at two or three keys per template the result is worse than not using the feature [13]. The crossover is around four to five keys, and the saving plateaus by about a hundred [14].
The loading-throughput claim needs the most reading. 500,000 hashes, three runs each way, timed inside the container with bash's `time` builtin so that `docker exec` overhead stayed out of the measurement, gave a 35% improvement over per-key HSET [15]. "I don't know what workload produces the blog's number, maybe a wider schema, maybe a network-bound client where skipping repeated field names in the wire protocol matters more than it does over a Unix socket to a local container," the author wrote [16]. For the 2x to show up on your cluster, the client has to be spending real time putting repeated field names on the wire; the 35% came from a bulk `redis-cli --pipe` load into a container on the same host [15].
What to watch
- Whether Redis documents any in-place conversion for live hashes that needs neither HIMPORT nor an RDB reload.
- Whether the throughput gap narrows on a genuinely network-bound client, one of the explanations the author offers for the blog's 2x.
- Whether managed Redis providers expose hash-rdb-load-min-template-entries and its two companions, since a hosted primary cannot convert without them.