RavenDB Multitenancy not that multi…

18.08.2017

Michał Kocik
Software Developer
Michał Kocik

When you design your system to be available for different group of users you will certainly encounter a problem how to bind data to particular group. You probably would add some sort of id to each structure like tenant id etc. With relational approach this is natural, however with document databases this is not perfect. It polluts your model with technical stuff and you have to remember to put it everywhere… In RavenDB this and some other problems have been addressed with feature called multitenancy. Although this is very convenient approach there are also some caveats you should be aware of.

What exactlty this multitenancy is and why you may want to use it?

In short, multitenancy in RavenDB is nothing else than having separate document database for each tenant, wherin the switch between databases is easy and optimized to be very efficient. This is very attractive and convenient because you don’t have to filter your data by specific tenant. You rather do all the queries in scope of tenant database so there is no risk that other tenant data will leak into your query result.

 

RavenDB Multitenancy. Where is the problem?

The problem with multitenancy is that each database uses read write I/O operations for changes in documents and to update indexes. This may cause botellneck when you have a lot of them trying to do I/O at the same time resulting in queries timeouts. Additionally it is worth to mention that when databases are idle for some period of time RavenDb unloads it from memory. However when you start quering many of that unloaded databases at the same time RavenDb has to load them again which may cause substansial I/O and resources usage, resulting in timed out queries and 100% processor peaks.

Another important thing is that all these databases needs to have resources like memory and threads allocated. So, more databases then more resource stravation and performance issue you may experience.

 

Is it worth the effort then?

Personally I think if you can do something to decrease complexity of your system then it is worth to consider. Multitenancy definitely does. However you should plan your environment duly in advance, make some load tests etc. to prove that it will handle your scenario. RavenDb performs much better with few bigger databases than thousands small one. Hence you should also consider to split your databases rather per bounded context than per tenant. This is what we finally did when we start coping with multitenancy problems.