Multiple databases v/s Multiple collections - MongoDB 3.2

1,676 views

Skip to first unread message

Nikhil Jain

unread,

Dec 17, 2015, 4:56:27 AM12/17/15

to mongodb-user

I know this question has been asked a number of times here. However, I am unable to find a satisfying answer and reach on a conclusion.

This question is specifically for Mongo DB version 3.2. Should I have separate DBs and collection for different apps, or just one DB with all collections within it?

To simplify it further, let’s say I have about 15-20k apps on a server. Is it advisable to create a different database for each of these apps (with 10 collections/app), or create just one database and store all collections (20k apps * 10 collections = 2 lac collections) in it?

I have also posted the question on stack overflow: http://stackoverflow.com/questions/34331320/multiple-databases-v-s-multiple-collections-mongodb-3-2

Thanks,

Nikhil

Kevin Adistambha

unread,

Jan 10, 2016, 11:59:00 PM1/10/16

to mongodb-user

Hi Nikhil,

What you are asking is a broad question with no single correct answer. It is more of a design question rather than any specific MongoDB issue.

MongoDB is perfectly capable of doing what you asked in your scenario (20k * 10 collections = 200k collections in a single db, or 20k db with 10 collections each, subject to open file limitations of the underlying OS). However, it is not advisable to push any technology to such extreme numbers without careful thought due to security, availability, and performance issue.

The page MongoDB Limits and Thresholds describes the limits of MongoDB capabilities in detail.

However, there are more important questions for you to consider depending on your use case, for example:

Backup: If you need to have a per-app backup, then grouping all apps into a single db will make this difficult to do. You therefore need to think about the best backup method.
Usage pattern: If some apps are more write-intensive while some other are more read-intensive, you need to consider document growth over time.
Geographic location affinity: For example, some apps have more users in North America, and some have more users in Asia. For this, you need to plan the data center awareness and the geographic redundancy of each app.
Data expiration: You may need to think about the data lifecycle of each app.

Those are just some of the basic questions off the top of my head. I’m sure there are many more that you can think of.