Multi-tenancy support


After reading the docs and looking through the source code, I could not find any reference to multi-tenancy support. Is this something keydb would consider as a feature?

Our use-case

We are currently running separate redis instances for each website/application we host on our kubernetes clusters (>100 sites). This is sub-optimal for several reasons:

  • extra number of pods => leading to extra overhead
  • memory usage
  • currently no HA setup for all websites as this would increase the number of pods + memory significantly

The ideal setup would be one (or several) redis clusters outside of our kubernetes clusters where we have a multi-tenancy/multi-user setup where each user has it’s own “namespace”.


Looking through the source code each client is associated with a database, and there seems like it would be fairly simple to use the authenticated user + database number into the lookup instead of only the database number. Do you think this approach would be feasible? Is there an upper limit to the number of databases? How would this impact performance / memory usage?

Another solution might be to auto prefix the keys based on the authenticated user, this however might lead to issues when listing keys and might lead data to (more easily) spill to other tenants.

Do you think multi-tenancy support would be possible as a module? Or is this something that needs to be in the core?

Kind regards,

Hello @ederuiter,

we are currently in a similar situation. One Redis instance per customer not much load per instance. We want to consolidate all customers to the same Redis/KeyDB but separating them by namespace/username whatever. I am looking for viable solution to accomplish this without changing our application.

Did you find a solution?

Hi @Vad1mo,

No I haven’t found a solution yet. I believe redis enterprise has a commercial solution for this (, but I am not aware of any open source solutions.

I have created a very rough poc for a multi tenant redis proxy. This proxy connects to redis/keydb via unix socket and listens for incomming requests on the normal redis port.
It uses the redis 6 acl system to limit users to their own key prefix, and it autoprovisions users, it currently uses reverse dns to determine the user (for now it only works for the supplied docker-compose setup, the idea is to determine the kubernetes namespace from the reverse dns and use that as username)

All of this is transparent to the client, all the keys are automatically prefixed and clients do not need to authenticate atm.

There are lots of things to do:

  • prefix pub/sub channels
  • support for commands returning keys
  • performance
  • …

But the basic premise already works

1 Like

I found this topic by looking for exactly what was described above. It doesn’t seem to exist at all? I don’t even care about the backend, as long as its Redis protocol compatible with the most basic commands and supports an unlimited amount of namespaces. Most won’t even be used or used once and can be purged later. Very few will actually generate any kind of load.

I really wanted to avoid having to build this ourselves, especially since it seems like there are companies doing the same thing out there but obviously closed-sourced.

For anyone who might be interested I found this project that seems to support multi-tenancy and replication with Redis protocol support

For those interested in using ACL’s, the documentation can be found here: . This was introduced in version 6 of Redis & KeyDB

If there are specific suggestions/requests on what would assist the use case more on the KeyDB server side, we would be interested in hearing it. Ie. is there something specific you would add or change from what is currently offered with ACL’s?

What I need (and I assume everyone else in this thread) is basically this

1 redis server/cluster that depending on the entered password creates a new namespace for the user. So pass 123 and GET value will result in 5
But pass 321 and GET value will result in 9

Because its completely different DBs.
So ACL is not helpful at all.

Another example

I even tried asking RedisLabs about the pricing of Redis enterprise but they simply started ignoring me once I told them how small we are.

An affordable version of that feature would be awesome.

Thanks for the clarification, this is a good feature request that we believe has a lot of value, and something we will look at adding to KeyDB

I have created issue #286 on github to track this. We do not yet have a timeline for this implementation but will keep the issue updated