Multiple Databases in MongoDB for SaaS

Question

I am building a SaaS application in node.js and want to use MongoDB for a database with the Mongoose ODM. I will need to support multiple customers, between hundreds and thousands (hopefully) and there is no interaction between the data of each customer.

My thought was to create a new database for each customer and a single "master" database which held global information. For example, there will be a single login page for the app, so I wanted to store all user/password info in the "master" database, but all the user's profile information within the customer's database to which they belong. I felt that this would be a good design as it would completely isolate each customers' data and make it easy to backup/restore a customer individually.

My concern is regarding the performance impact of connecting to multiple databases from node.js. Does anyone know how that would impact that app, or any opinions about the architecture in general?

Bonus Question: Do you know of any audit implications of doing the reverse and storing all customer's data in a single DB, separated with a customerid, in a SaaS solution?

Answer 1

Not an easy answer because a lot depends on your app architecture, usage and query patterns, the distribution among clients (ie: will the usage levels be roughly the same across clients, or could you have 10% of the clients using 90% of the resources), how much you can spend on code vs ops management and a whole host of other issues. Here are some things to consider:

1) having one database will make your ops management easier, require less computing resources, and may allow you to scale out better, but coding the access layer will be more difficult and you really have to architect your security layer well for obvious reasons. You'll also consume less resources on the client/webserver end since there will be many fewer connections.

There are two popular schema options when approaching one monolithic database:

• You can put all similar data in one collection (ie: profiles for all accounts go into the same collection) and give each document a clientid key to identify which data belongs to which account. This may provide you the best options (depending on your schema architecture) for scale out with the fewest computing resources.
• Another option is to separate client data by collections - each client will have their own collections within the database identified with a clientid prefix (ie: clientid_userprofiles).

2) the database per client option will give you more ops management headaches and cost more as you will need more more computing resources. On the other hand, your coding costs should be less as the code will be easier to write. It will also allow you to better distribute your resources between heavy and light users. For example, you can move heavy usage clients to more powerful machines and provide sharding on a per customer basis.

3) you could provide a combo of the two options - dedicated databases for high end users (accounts that pay more), and then a shared database with data separated by collection for low-end clients and test/freemium accounts.

Note that if you do go the many database route, you should look into the --smallfiles startup option. This will help you with situations where you have a lot of people setup "test accounts" but who don't do very much with them.

Anyway, hopefully the above gives you food for thought. Do a search on https://groups.google.com/forum/?fromgroups#!searchin/mongodb-user/multitenant as there have been a number of discussions in the Mongo forums on this specific issue.

As for the audit implications, depends what level of auditing compliance you need to adhere to. If you expect fortune 1000 clients, your compliance requirements will be far higher (and way more costly - think $10s to $100s of thousands of dollars), than if your clients are startups who may never have heard of SAS70, etc. The answer also depends on what type of data you are storing - is it user financial data, or is it just user forums? Basically, if there are any concerns about needing to pass security audits for large companies in the future, don't even think of the shared database approach.