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.