Building Fast, Scalable Multi Tenant Apps with MongoDB

landlord_and_tenantMULT TENANT

We are all building apps in the cloud. Accounting apps, to-do apps, word processing apps everything. With clients trusting you with their data, the question becomes how to keep their data safe and separate. Keeping your client’s data separate is the difference between living in a group commune and being a tenant in an apartment. This is called multi-tenancy.

Multi-tenancy refers to a principle in software architecture where a single instance of the runs on a server, serving multiple customers (tenants). This is a really important part of an important feature of cloud computing. This is important because in multi-tenant environment customers do not share or see each other’s data.

There are three main ways to build multi-tenant databases in MongoDB. The first is by putting all tenants in a single database. The second is putting each tenant in their own individual database, and finally, each tenant in its own collection.


This is the most common form of multi-tenancy and where most web apps start. Putting all your tenants together is a lot simpler and we do not even think about calling it multi-tenancy. Putting all tenants in a single database requires putting the multi-tenancy logic into the application level. Enforcing security at the application level can be something as simple as placing an enforcing user or customer filters on all data queries, eg.  prefixing every database query with a user id.

For a “freemium” business, this will be a better model, since each MongoDB database occupies at least 32MB.  Creating hundreds of databases for hundreds of non paying customers can waste a lot of resources.


This is probably the worst way for MongoDB for a couple of reasons. I won’t go into detail, but this is the method you really want to avoid.

First, Collections in the same database share the same database Lock. MongoDB concurrency has been steadily improving, but it is still there. Second, the default MongoDB nssize setting limits the number of collections in a database to 24,000. You can go up to 3 million by changing the nssize setting in the configuration.


The may be the best way depending on your app. Giving each tenant their own databases gives you flexibility in managing and optimizing your MongoDB setup. By having a separate database per customer, things like great for moving, managing and deleting client databases become trivial. Since each database is separate, you can create different indexes for different clients depending on their needs.

The downside to this is that each client takes space. If your clients are paying customers, this is not a problem. If you have a free service, then each client will use 32 MB of disk space which is quite a lot if you have a lot of inactive clients.

Even with multi-tenancy, it can be hard to pick a shard key. The hashed shard key in MongoDB can provide performance even at scale ( depending on your application )


For most things, performance is application specific. Especially with MongoDB, and the advice here needs to be seen in the light of your application. As always, your mileage may vary. Wou are starting an app, for development, you can certainly use one large database while writing your app logic to support One database per tenant. You may not use this initially with your app, but by   putting multi database logic in your app code from the start will save you a lot of heartache if you have any sort of success. And one last thing. Shard Early Picking a shard key is something that is hard to change later



4 thoughts on “Building Fast, Scalable Multi Tenant Apps with MongoDB

  1. Thank you for your Article, but Please can you give us more information.
    Please how are you differentiating your tenants ?
    are you doing it based on subdomain ?
    Do you have a master db of tenants ?
    Are you creating each tenants db connection to the mongodb database on the fly ?
    Does each tenant have its own app instance (node js running on a seperate process) ?

    Thank you very much

    • You need a master database tenants and pass the information on the in something like the URL , a login a subdomain or key. You would differentiate your clients at account creation, also using the same information you would use in a master database. Your question is basically the same, and that is something that you will have to decide when you arch you system.

      How the tenant databases connect would be up to your stack. You really do not want to open and close connections for each pageview. You will end up with ‘connection churn’ that will hurt your performance. Your stack should take advantage of connection pooling in the client.

  2. If we have separate database for different customers, won’t it be very difficult to do a database migration when we have 1000+ clients ? I echo the question of Moyo Falaye in a different way. When we scale to 1000+ clients, are we going to use a load balancer?

    • First, I think your question touches two separate issues. The first is load balancing with s sharded cluster and the second is migrating a lot of clients.

      So, no you would not need a load balancer in general. If you have a group of mongos instances and use a load balancer between the app and the mongos, that would be a possibility. However, I would use the mongos instead of placing a load balancer in front of them.

      On doing a database migration, if you are running a sharded setup, no migration to an new , larger server is not a problem is can be handled by MongnDb. All the databases are located on the MongoDB cluster, so I am not quite sure what you mean by ‘migration’.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s