How much space does an additional database take up? How many databases can I have?

In my MySQL days, we built a hosted product which used a separate MySQL database for each customer's instance. This worked well because the per-database cost of just having one more database (not necessarily a particularly active one) was low. It didn't have a large incremental cost in RAM or disk space. It also meant sharding was easy because we could just move your database.

What is the minimum cost in RAM or disk space to add one more MongoDB database? I've been trying to suss it out but there's always something else happening which makes it hard to measure reliably. It looks like it might be at least 80MB in disk space.

Since MongoDB has no "create database" command, let's define "adding a database" as inserting something into a collection and/or ensuring it has an index, either of which automatically brings it into being.

Also, by "a database" I mean "use foo" versus "use bar" - distinct databases in mongo terminology.

I am not the expert in all things Mongo, but I think I can help, because I've asked similar questions before. 

A standard MongoDB instance can handle a good number of databases. There is no clear answer as to how many. You'll learn with MongoDB, the answer to any question is almost always, "it depends". For instance, if you have a lot of customers, who have low activity needs for the database, you could probably have a lot more on a single instance, than you could have, if say, the customers would have high database loads. It also depends on the hardware used. If your server cluster has limited RAM or storage or CPU or network throughput, the ability to support a larger number of databases is also limited. This is the same for any database though. 

You mentioned a concern about disk space and file sizes. MongoDB has a pre-allocation system for the data files and every MongoDB database (they do have the same name as in MySql) is started with 3 standard files with, I believe, 256MB. That is because there are three files created and pre-allocated. One is the NS file for the namespaces with 64MB  and the other two are data files with 64MB and 128MB. This allocation increases too, once the next file is created, meaning, the next file will be 256MB. The file after that will be is 512MB, then 1GB and finally 2GB. Every new file after that will be 2GB. The next data file is also created, when the last file first gets data in it. So in worst case, you could have a customer with just over 1 GB of data taking up 3GB of space. Of course, as the data size grows to hundreds of GBs, the pre-allocation of 2GB files becomes irrelevant. But for a lot of "smaller databases", this could become a concern. 

There is also currently a new storage engine being worked on called WiredTiger, which will be released with 2.8.0 (hopefully). This storage system is much better in terms of disk usage and also even has data compression, which I am personally very interested in.

The last concern you mentioned is RAM, which is a very important concern with MongoDB. You see, Mongo's way of working, to be as performant as possible, is to use RAM. (Which is a no brainer). And the answer to this concern is.....yep, you guessed it...."it depends". 

RAM holds the "Working Set" and also any indexes of the databases. Having all the indexes in RAM isn't a necessity, but it is recommended for fastest performance.(also a no brainer). I've tried to nail down what the "Working Set" is or will be for any given amount of data on disk, but with the Memory Mapping system Mongo uses, it is basically impossible to determine, because it depends on what data is being called upon in what amounts. The more data queried, the more to be fit in RAM, the larger the working set. I guess the answer is a bit different or rather you need to think of the system as a whole a bit differently. The answer isn't, "you need enough RAM to hold your databases", it is more like, "you need enough RAM to support your data storage activity and do it with a certain level of performance".  if performance starts to drop, because you are over using the database system, then you need to scale up or out (the choice is yours!).  

And that leads to what makes Mongo so great. If you set up a Mongo system properly, you can scale vertically or horizontally quite easily. Actually, with just a press of a button or even completely automated. So, for a "hosted solution", where flexibility is key, it is a pretty neat solution for larger databases, because it solves a lot of "scaling" issues. For a lot of smaller databases, it will work, but with some limitations I pointed out above. Maybe WiredTiger will help fix those limitations. I hope so.:-)

Hope I could help.