A service stores one Redis hash per user session, and a new feature proposes merging in a second, related hash of many more fields under the same key rather than keeping two separate hash keys, on the grounds that "one key is simpler." What actually changes about the memory cost as the merged hash grows, and why isn't merging automatically the cheaper choice?

A small Redis hash is stored as a listpack — one compact, contiguous block with no per-field pointers — and the lesson measured that at 16 bytes per field for a 10-field hash. Past a configured entry-count threshold, Redis converts the whole hash to a real hash table, which costs far more per field — 56 bytes per field at 1,000 fields in the lesson's measurement, about three and a half times more. A hash's encoding is decided per key, by that key's own field count, not by how many other keys exist, so two separate small hashes can both comfortably stay in the cheap listpack encoding on their own. Merging them into one bigger hash moves the combined key closer to the threshold, and if it crosses it, every field in the merged hash — including the ones that were cheap on their own — pays the switch to the more expensive encoding, not just the newly added ones.