I know the question has been posted before, not answered thoroughly though. Also I think it still depends on the problem parameters. Lets say you have a SaaS service with a lot of customers but with relatively small amount of data per customer, it probably makes sense to have a single database.
What happens in the case where your customers will longterm be not in the range of thousands (eg. 100 in a very good scenario) and start with 5 – 6 but you have lots of data per customer this time (eg. a business intelligence service which aggregates and processes tons of data). To give you a hint, 25 – 50GB of data to process (analytics and other stuff) per customer initially, as a start and then add about 10GB per year per customer.
If you go down the path of a single db, then you tag the data to a customer with a specific field (indexed of course) and then rely on a replication and sharding system which is pretty straightforward thanks to mongo. I assume ( haven’t tested and if you have such case please share some insight) that in a sharded collection against indexed fields query lookup time should be fast.
However let’s say you add another customer now, another 50 GBs (spread accross 8 – 10 collections, hence many millions of items / collection). You either have to:
1) drop indexes and rebuild them ( i guess thats the worst because system becomes practically unusable)
2) dont drop and insert with indexes (it will take forever), system will be responsive
3) I would think in a replica set take down a node, drop indexes, update with new customer, bring back indexes and then have it join the replica set so that they can begin syncing.
In the other hand, if you have one db per customer, adding or removing can be done relatively quickly because the system practically isolates its customer, rows are in still in the range of many millions but not close to billion, which is good and lookup times are obviously fast. Whatever your doing in this case, it’s much easier and quicker in terms of implementation simply because you will always work with a relatively smaller number than in the case of a single db. However when it comes to maintenance (replication & sharding because you will keep adding more data per customer) it’s going to be a friction for sure
Plus in this case I would probably assume that you have to physically isolate dbs in seperate machines / instances, because of the OS limit of number of open files and of course there would be an extra overhead due to multiple simultaneous connections in multiple dbs.
If I missed something please do shed some light, but I am most interested to hear other opinions on this…
Thanks
I’d suggest a DB-per-customer if you’re staying in the low hundreds of customers, collection-per-customer if you expect more customers than that. (There is some per-database overhead that you won’t want to incur for thousands of DBs.)
Note that your idea, “I would think in a replica set take down a node, drop indexes, update with new customer, bring back indexes and then have it join the replica set so that they can begin syncing.” will not work since in a replica set only the primary can take writes.