it is quite large, 2^64-1 in 64 bit systems, and 2^32 -1 in 32 bit systems, https://groups.google.com/d/msg/redis-db/eArHCH9kHKA/UFFRkp0iQ4UJ

1) Number of keys in every Redis database: 2^64-1 in 64 bit systems. 2^32-1 in 32 bit systems. 2) Number of hash fields in every hash: 2^64-1 in 64 bit systems. 2^32-1 in 32 bit systems.

Given that a 32 bit instance has at max 4GB of addressable space, the limit is unreachable. For 64 bit instances, given how big is 2^64-1, the limit is unreachable.

So for every practical point of view consider keys and hashes only limited by the amount of RAM you have.

Salvatore

I did a couple of quick tests for this using the lua client.

I tried storing 100,000 fields using a single hmset command, individual hmset commands, and pipelined individual commands, and timed how long they took to complete:

hmset 100000 fields: 3.164817

hmset individual fields: 9.564578

hmset in pipeline: 4.784714

I didn't try larger values as 1,000,000+ were taking too long but the code is here if you'd like to tinker. https://gist.github.com/kraftman/1f15dc75649f07ee044eccab5379a8e3

Depending on the application bear in mind that you loose the storage efficiency of hashes once you add too many fields('too many' can be set, see here for more info.

actually the number of fields you can put inside a hash has no practical limits (other than available memory)

I think there's no performance penalty to save data in a HASH . However, if you have a very large HASH , it's always a bad idea to call HGETALL . Because HGETALL returns all fields and values of the HASH , and that would block the Redis instance for a long time when the HASH is very large.

Whether a HASH is better than key-value store, largely depends on your scenario.