What is the recommended approach towards multi-tenant databases in MongoDB?

Question

I'm thinking of creating a multi-tenant app using MongoDB. I don't have any guesses in terms of how many tenants I'd have yet, but I would like to be able to scale into the thousands.

I can think of three strategies:

1. All tenants in the same collection, using tenant-specific fields for security
2. 1 Collection per tenant in a single shared DB
3. 1 Database per tenant

The voice in my head is suggesting that I go with option 2.

Thoughts and implications, anyone?

Answer 1

I have the same problem to solve and also considering variants. As I have years of experience creating SaaS multi-tenant applicatios I also was going to select the second option based on my previous experience with the relational databases.

While making my research I found this article on mongodb support site (way back added since it's gone): https://web.archive.org/web/20140812091703/http://support.mongohq.com/use-cases/multi-tenant.html

The guys stated to avoid 2nd options at any cost, which as I understand is not particularly specific to mongodb. My impression is that this is applicable for most of the NoSQL dbs I researched (CoachDB, Cassandra, CouchBase Server, etc.) due to the specifics of the database design.

Collections (or buckets or however they call it in different DBs) are not the same thing as security schemas in RDBMS despite they behave as container for documents they are useless for applying good tenant separation. I couldn't find NoSQL database that can apply security restrictions based on collections.

Of course you can use mongodb role based security to restrict the access on database/server level. (http://docs.mongodb.org/manual/core/authorization/)

I would recommend 1st option when:

• You have enough time and resources to deal with the complexity of the design, implementation and testing of this scenario.
• If you are not going to have much differences in structure and functionality in the database for different tenants.
• Your application design will allow tenants to make only minimal customizations at runtime.
• If you want to optimize space and minimize usage of hardware resources.
• If you are going to have thousands of tenants.
• If you want to scale out fast and at good cost.
• If you are NOT going to backup data based on tenants (keep separate backups for each tenant). It is possible to do that even in this scenario but the effort will be huge.

I would go for variant 3 if:

• You are going to have small list of tenants (several hundred).
• The specifics of the business requires you to be able to support big differences in the database structure for different tenants (e.g. integration with 3rd-party systems, import-export of data).
• Your application design will allow customers (tenants) to make significant changes in the application runtime (adding modules, customizing the fields etc.).
• If you have enough resources to scale out with new hardware nodes quickly.
• If you are required to keep versions/backups of data per tenant. Also the restore will be easy.
• There are legal/regulatory restrictions that forces you to keep different tenants in different databases (even data centers).
• If you want to fully utilize the out-of-the-box security features of mongodb such as roles.
• There are big differences in matter of size between tenants (you have many small tenants and few very large tenants).

If you post additional details about your application, perhaps I can give you more detailed advice.

Answer 2

I found a good answer in the comments in this link:

http://blog.boxedice.com/2010/02/28/notes-from-a-production-mongodb-deployment/

Basically option #2 seems to be the best way to go.

Quote from David Mytton's comment:

We decided not to have a database per customer because of the way MongoDB allocates its data files. Each database uses it’s own set of files:

The first file for a database is dbname.0, then dbname.1, etc. dbname.0 will be 64MB, dbname.1 128MB, etc., up to 2GB. Once the files reach 2GB in size, each successive file is also 2GB.

Thus if the last datafile present is say, 1GB, that file might be 90% empty if it was recently reached.

from the manual.

As users sign up to the trial and give things a go, we’d get more and more databases that were at least 2GB in size, even if the whole of the data file wasn’t use. We found this used a massive amount of disk space compared to having several databases for all customers where the disk space can be used to maximum efficiency.

Sharding will be on a per collection basis as standard which presents a problem where the collection never reaches the minimum size to start sharding, as is the case for quite a few of ours (e.g. collections just storing user login details). However, we have requested that this will also be able to be done on a per database level. See http://jira.mongodb.org/browse/SHARDING-41

There are no performance tradeoffs using lots of collections. See http://www.mongodb.org/display/DOCS/Using+a+Large+Number+of+Collections