Redis 8. 10's compact hashes need HIMPORT or a restart to kick in
Redis 8.10 introduces compact hashes that share field names across keys, offering up to 50% memory savings and double the load speed. In practice, savings depend on schema design and require HIMPORT or a server restart to activate. The feature also has limits and can increase memory if misused.
When Redis 8.10 launched in July, it added a new encoding called compact hashes. The idea is simple: if many hash keys use the same set of field names, Redis can store that set once and let every hash point to it. The release notes promised up to a 50% drop in memory usage and a two‑fold increase in loading throughput.
What the Numbers Really Show
To test the claim, I ran Redis 8.10.1 in Docker and loaded 100,000 hashes twice: once with the classic HSET command and once with the new HIMPORT pair. The first schema was a typical user profile with four short fields: name, email, country and last_login. The second schema was designed to favor the feature, using eight long field names that hold short flag values.
For the simple profile, the memory per hash dropped from 159.9 bytes to 127.6 bytes—a 20.2% reduction. For the flag‑heavy schema, the drop was 67.8%, from 271.3 bytes to 87.3 bytes. The advertised 50% figure is therefore workload‑dependent: it is reached only when the schema’s memory is dominated by field names rather than values.
Throughput Is Modest, Not Double
The blog also claimed that HIMPORT could load hashes twice as fast as HSET. I measured 500,000 hashes with both commands, timing the operations inside the container to avoid Docker overhead. The fastest run for HSET was 185,323 hashes per second, while HIMPORT hit 251,004 hashes per second—a 35% improvement, not 200%. The benefit is real for bulk loads, but the magnitude depends on the workload and the network path.
Plain HSET Gets Nothing Until You Restart
One of the most surprising findings was that a hash written with plain HSET never becomes a compact hash while the server is running. Redis only folds a hash into a template in two situations: when you use HIMPORT, or when you load an RDB file with three special configuration flags turned on. By default those flags are off, so a restart with them enabled is required to convert existing hashes.
I initially set the flags at runtime with CONFIG SET, ran BGSAVE, and restarted the container. Nothing changed because the settings were not persisted. After restarting with the flags passed as command‑line arguments, a BGSAVE followed by a container restart converted all 100,000 plain hashes into a single shared template, dropping memory from 17,459,464 bytes to 14,182,656 bytes—a 18.8% saving that matched the HIMPORT test.
When Shared Templates Backfire
Compact hashes have a fixed overhead. If only a few keys share a template, the overhead can outweigh the savings. I measured memory usage for the first key in a group of shared hashes: two keys used 156 bytes, three used 129 bytes, and the overhead disappeared around five keys. With 1,000 keys sharing a template, each key used 76 bytes—slightly better than the 112 bytes of a plain hash. Thus, for small batches of short‑lived hashes, the feature can actually cost more memory.
Mutating a templated hash also has side effects. Adding an extra field or deleting an existing one forces Redis to create a new single‑key template for that hash. The mutated key grows from 76 bytes to 265 bytes, and the deleted key grows to 208 bytes—worse than a plain hash. The rest of the group remains unaffected.
Connection‑Scoped Fieldsets and Concurrency
The HIMPORT fieldset is scoped to a single connection. If a client uses a connection pool, a request that lands on a different connection will fail with an error. Each connection must run HIMPORT PREPARE before it can issue HIMPORT SET commands. However, when multiple connections prepare the same field names independently, Redis deduplicates them server‑side and ends up with a single shared template, even under concurrent writes.
What to Do Next
If your application already writes thousands of hashes with a consistent schema, consider using HIMPORT for bulk loads and ETL pipelines. For regular writes, enable the RDB‑load flags and restart each node to convert existing data. Always monitor hash_templates and hash_template_keys in INFO stats to ensure the feature is providing a benefit. Avoid small, infrequent batches of hashes under a template, and be careful when mutating templated keys.
Why it matters
Redis users looking to squeeze more data into memory will benefit from understanding when compact hashes actually save space and how to activate them. Misusing the feature can lead to higher memory usage and operational headaches.
Key points
- Compact hashes share field names, offering 20‑70% memory savings depending on schema
- HIMPORT or a server restart is required to activate the feature for existing hashes
- Throughput gains are around 35%, not the advertised 200%
- Small groups of shared keys can increase memory usage
- Mutating a templated hash creates a new template, enlarging the key
Frequently asked questions
How do I enable compact hashes for existing data?
Set the three hash‑rdb‑load flags via the command line, run BGSAVE, and restart the server. The hashes will be converted during the RDB reload.
Can I use HIMPORT in a production write path?
Only if you can change the write logic. For bulk loads and ETL jobs, HIMPORT works well, but regular writes should keep using HSET unless you plan a restart.
