RENAME and RENAMENX in Redis - Time & Space Complexity
When working with Redis keys, renaming them is common. Understanding how the time it takes scales with the number of keys helps us write better code.
We want to know how the cost of renaming keys grows (or stays constant) as the database size changes.
Analyze the time complexity of the following Redis commands.
# Rename a key to a new key name
RENAME oldkey newkey
# Rename a key only if the new key does not exist
RENAMENX oldkey newkey
These commands change the name of a key in the database, either unconditionally or only if the new name is free.
Look for repeated work inside these commands.
- Primary operation: Redis looks up the old key and the new key once each.
- How many times: Each key is checked or updated only once per command.
The time to rename is constant and does not depend on the size of the key's value or the total number of keys.
| Input Size | Approx. Operations |
|---|---|
| Small (10 bytes, small DB) | Constant time |
| Medium (1000 bytes, medium DB) | Constant time |
| Large (1000000 bytes, large DB) | Constant time |
Pattern observation: The time is always O(1), independent of the size of the data stored in the key or the number of keys in the database.
Time Complexity: O(1)
This means the time to rename is constant, independent of the size of the key's value or how many keys are in the database.
[X] Wrong: "Renaming a key requires scanning all keys in the database, O(N)."
[OK] Correct: Redis uses hash tables for O(1) key lookups and updates. No scanning is needed.
Knowing how Redis commands scale (like O(1) for key renames) helps you design efficient data operations and avoid surprises in real projects.
What if we renamed a key that holds a very small string versus a large list? The time complexity is O(1) in both cases; it does not change.