As we’ve been introducing Valkey/Redis these past few weeks, let’s depart from the norm and talk about a few “things you should not do” in Valkey.
No password
By default, Valkey/Redis uses no authentication. This means anyone can connect to your Valkey server and start writing and reading data. Worst yet, no password while binding to all interfaces could expose your Valkey server to the world.
Thankfully, Valkey enables protected-mode by default. If the default user has no password, Valkey only accepts connections via localhost (e.g.,127.0.0.1), even if bound to other interfaces.
To correct this, ensure the default user has a password or create application-specific users using access control lists (ACL).
1 2 3 4 5 6 | requirepass mysupersecretpassword - OR - user default on >mysupersecretpassword allcommands allkeys user appuser on >myappsecret +@list ~jobs:* |
The above appuser can only execute commands related to LISTs (eg: LPUSH, RPOP, LLEN, LRANGE, etc), and can only execute those commands on keys that begin with ‘jobs:’
Dumping everything
At some point in your development cycles, you may get tempted to just ask “give me every key in the database” and then run ‘KEYS *‘ which will dump out every key for everything stored in Valkey. This is bad. Imagine having tens, or hundreds of millions of keys and you’ve asked Valkey to iterate through all that memory. Valkey is single-threaded so that scan will be blocking to the next clients.
Instead, opt to use SCAN, SSCAN, HSCAN, or ZSCAN which iterate over all keys, set keys, hash keys, or sorted-set keys, respectively. These commands return a cursor which allows you to iterate through the keys, in a non-blocking way.
Additionally, watch out for unbounded range, and member scanning functions like HGETALL, SMEMBERS, and ZRANGE. You may be tempted to “SMEMBERS myset” which will return all the members of a set, or “ZRANGE myzset 0 -1” to return all elements in the sorted set. Instead, opt for “SSCAN“, or “ZSCAN” to iterate through the sets in smaller batches.
Frequently used keys
If you’re not running Valkey / Redis clustering, then this isn’t really an issue for you. However, if you are, then this can be a big deal.
When you set up clustering in Valkey, the server which holds the key you are storing/requesting, is determined by first hashing the key. If you have a few frequently used keys, they may hash to the same Valkey cluster member. This will cause an imbalance in the number of requests sent across the cluster. You might end up with 1 super hot Valkey server (ie: busy CPU), and 3 mostly-idle servers.
Try to use more fine-grained keys which will hash to multiple members. For example, you could create a single hash key called ‘user_sessions’ and store userId => sessionId mappings in the hash. This key is used all over the application and would create a hotspot on one of the cluster members.
Instead, create separate keys for each user, for example: “user:42:sessionid” and store the associated sessionId value on this key. With 10s of thousands of users, you’ve now spread the load across all your cluster members.
Not having a backup
This falls under “don’t run Valkey without disk persistence.” Again, thankfully, Valkey comes with disk persistence enabled by default. With the default config, Valkey will save every hour, every 5 minutes, and every 1 minute, provided at least 1, 100, or 10000 writes have happened, respectively. This is a background save, where Valkey will fork() itself, into parent and child processes. The parent continues serving requests from clients, while the child, which received a copy of the memory contents at time of fork, will save everything to disk and then exit. Tune these auto-save frequencies to match your data volume, and data-loss risk.
If you plan to use Valkey as a pure caching solution, where the cached data can easily be recreated, you can disable these ongoing backups by setting ‘save “”‘ in your config. You could still use ‘BGSAVE‘ (which operates as described above), or ‘SAVE‘ which blocks/locks the entire server for the duration of the flush to disk, as-needed.
The automatic save to disk creates a point-in-time snapshot of the Valkey server. If you want a more up-to-date backup, consider enabling the Append-Only File (AOF) mechanism. The AOF system records all write activity to a series of append-only log files (hence the name). On Valkey startup, a snapshot is restored, and the AOF files are replayed to bring the server back to a point in time, just before disaster.
Using other databases
You may not know this, but Valkey/Redis does have a concept of “databases”. There are 16, by default, with the default database being “database 0 (zero)”. You can switch to another database using ‘SELECT X’. This creates complete isolation from other databases.
However, using different databases is not considered best practice. Even the original author of Redis, Salvatore Sanfilippo, says not to use them. Additionally,
- Valkey is single-threaded, so even with multiple databases, you are limiting your capacity to a single thread.
- Valkey clustering does not support anything other than database 0. If you use multiple databases, they will not be replicated in your clustered environment.
- Valkey holds statistics for the entire server, not on a per-database level. Your monitoring system would not be able to show different statistics for the different databases, other than simple key counts.
Databases may be good for a dev environment to test different applications, or scenarios, but they should not be used in production. Opt instead to spin up additional Valkey servers.
Conclusion
Typically we see posts about ‘best practices to follow,’ but instead, today, we get a view of the inverse of that as ‘things not to do’ in Valkey/Redis. We now know not to run Valkey without users and/or passwords. We learned not to use massive key dump commands, and that running without data persistence could be disastrous. Also, a few hot keys can create imbalances across our cluster’s usage. And finally, using multiple databases in Valkey has a few important downsides.
