Redis Key Namespacing Strategies for Multi-Tenancy Compared

1. Why multi-tenancy in Redis requires an explicit decision

Unlike relational database systems with their own schemas per tenant or dedicated access rights per table, Redis offers no built-in tenant separation out of the box. Every key lives in a flat, global namespace within its logical database, and without a deliberate convention, keys belonging to different tenants can collide or overwrite each other.

This openness is an advantage on one hand, since it allows maximum flexibility in choosing an isolation strategy, but it is also a risk on the other, since separation can silently erode without a documented naming convention as soon as new developers or new services join. That is exactly why the namespacing strategy must be deliberately fixed from the start, not bolted on later as a stopgap.

2. Prefix-based namespaces in detail

In this approach, every tenant gets a unique prefix prepended to every key, for example tenant:123:cache:product:456 for product 456 of tenant 123. All tenants share the same Redis instance and the same logical database, separation exists purely at the application level through convention, not through a technical barrier inside the server itself.

The big advantage of this model lies in its unrestricted scalability: since all data lives in a single flat keyspace, the instance can easily run as a Redis Cluster with hash slot sharding, which becomes noticeably more complicated with the other two strategies. The downside is the lack of technical isolation: a bug that accidentally uses the wrong prefix or forgets the prefix entirely can mix data across tenants without Redis itself preventing it.

# Prefix convention per tenant, shared database
SET tenant:123:cache:product:456 "..."
SET tenant:789:cache:product:456 "..."
SCAN 0 MATCH tenant:123:* COUNT 100

3. Logical databases via the SELECT index

By default, Redis supports sixteen logical databases within a single instance, addressed via a numeric index from 0 to 15, between which a client switches using the SELECT command. In this model, each tenant would get assigned its own database number, so FLUSHDB deletes only that one tenant's data specifically, without touching the others, which already represents a real security improvement over the pure prefix model.

The limits of this approach show up quickly, though: Redis Cluster fundamentally only supports database 0 and outright refuses the use of multiple logical databases, which rules out this strategy for horizontally scaled cluster setups from the start. On top of that, no separate ACL permissions can be granted per logical database, so a user either has access to all sixteen databases or to none, which erodes isolation again at the permission level.

# Tenant 123 uses database 3, tenant 789 uses database 7
redis-cli -n 3 SET cache:product:456 "..."
redis-cli -n 3 FLUSHDB
redis-cli -n 7 SET cache:product:456 ".."

4. Fully separate instances per tenant

The maximum level of isolation is assigning every tenant its own, fully independent Redis instance with its own process, its own port, and its own configuration. This separation is real at the operating system level and can be hardened further with its own network segments, its own TLS certificates, and its own ACL users, without depending on application-side conventions at all.

The price is a noticeably higher operational burden: every instance must be monitored, updated, and sized individually, and the number of instances grows linearly with the number of tenants, which quickly turns into barely manageable infrastructure at several dozen or even hundreds of tenants. On top of that, every instance carries a fixed memory overhead for internal data structures, which adds up proportionally with a very large number of small tenants.

5. Isolation trade-offs and the noisy neighbor problem

A central risk of shared instances, regardless of whether separation is via prefixes or logical databases, is the noisy neighbor problem: since Redis operates largely single-threaded internally, a compute-heavy command from a single tenant, such as an unfortunately written Lua script call or a large sort operation, can noticeably slow down the entire instance for every other tenant.

Separate instances solve this problem structurally, because every tenant gets its own compute capacity and its own event loop. Within a shared instance, the risk can only be limited, never fully eliminated, through careful command filtering via ACL categories, consistently using non-blocking command variants like SCAN instead of KEYS, and strict monitoring of compute-heavy operations per tenant.

6. Backup granularity depending on the strategy

With separate instances, a selective backup or restore of a single tenant is trivial, since the RDB snapshot or AOF file contains nothing but that tenant's data anyway. With logical databases, at least a targeted export of a single database can be realized via DUMP and RESTORE per key, or via SELECT combined with an external script, though with noticeably more custom effort than with separate instances.

With the pure prefix model, a targeted restore of a single tenant is the most expensive, since neither RDB nor AOF supports native filtering by prefix. In practice, the only option is a SCAN over the matching prefix pattern followed by a DUMP of every key found, a procedure that costs noticeable time on very large key counts and needs to be custom built for a regular, automated backup per tenant.

7. Scaling: sharding per tenant versus a global cluster

Prefix-based namespaces combine most elegantly with Redis Cluster and hash tags: a hash tag like {tenant:123} within the key name ensures every key of the same tenant maps to the same hash slot and therefore the same cluster node, which still allows multi-key operations within one tenant while spreading the overall load across many nodes.

Logical databases are practically ruled out for cluster setups, since Redis Cluster only supports database 0, and separate instances do scale independently per tenant, but require their own orchestration layer that decides which tenant runs on which physical or virtual machine, which becomes its own substantial operational project under strong tenant growth.

8. Migrating between models without losing data

A common trigger for a strategy change is a planned move to Redis Cluster, once a multi-tenant setup previously separated through logical databases hits its limits. Since Cluster only supports database 0, every key in databases 1 through 15 has to be given a matching prefix and merged into database 0 before cluster mode can even be enabled.

In practice, this migration runs safest through a transition phase with dual writes: the application already writes new data in parallel under the new prefix scheme into database 0, while reads are still preferentially served from the old logical database for the time being, until a background process gradually transfers all remaining legacy data via SCAN and MIGRATE and the application then switches over completely to the new scheme.

# Migrate keys from database 3 with a new prefix into database 0
redis-cli -n 3 --scan MATCH "*" | while read -r key; do
  redis-cli -n 3 MIGRATE 127.0.0.1 6379 "tenant:123:$key" 0 5000
done

9. Practical recommendation for multi-store Magento setups

For a Magento setup with several store views sharing the same cache layer, a combination has proven itself in practice: for the full page cache and the object cache, a prefix-based naming scheme per store view is recommended, since Magento already natively supports this prefixing through its cache ID prefixes, and future cluster capability is not blocked by it.

For sessions, on the other hand, which need to be clearly separated per tenant and regularly cleared in a targeted way, a dedicated logical database is a good fit as long as no cluster topology is in use, since FLUSHDB provides a targeted, low-risk tool for resetting a single store's sessions. Only with a very large number of independent tenants with their own compliance requirements, such as a white-label operation with legally separate customers, does the extra effort of fully separate instances fully pay off.

10. Summary

11. FAQ: Key Namespacing in Redis: Key Takeaways