MongoDB: Limit user to find documents only by ObjectId

You are not missing the point :)

The key is how many reads and how many writes do you have to do when you store/update/fetch various entities in your collections?

You are presumably constantly (daily?) creating new posts and frequently creating new comments, and very frequently querying posts.

Actions like updating authors' email are very rare compared to the above. You want to optimize the performance of reads and writes that happen hundreds or thousands of times per in your application, and worry less about performance of very infrequent actions.

Having said that, I would store the basic author information embedded in the post, but I would only have information there that must be displayed with every post. If there are additional details about the author I want to keep in its own collection, I would expect that would be details that the user needs to click additional link to see (allowing for time to do another read).

My answer is : It depends. If you are accessing files by _id field, which is already indexed then you don't need to add more memory soon.

The _id field which is type of ObjectID is 12 byte in size. That means it can hold up to 2^(12*8) files. 3 byte is for machine ID which is a hash value and has a fixed vale on the machine can be subtracted which gives you approx 2^72 files. For the reference, 2^20 is 1,048,576.

In terms of the memory, the index on the _id field needs 10,000,000 x 12 byte = 114 MiBytes. To be honest, I don't now how much overhead there will be for an index which holds 10 millions value but I don't think that it will need more than 1 Gigabyte.

Now, if your _id field is not a type of ObjectID than do the math.

In the gridfs, filename value of the files collection is also indexed. If you are not accessing files using filename, then you may leave it blank and drop the index for the filename.

On the other side, if you will add some metadata to the files you added and want to query the files according to those metadata, then you should have indexes for those metadata and do the math again.

I have a production environment which has over 3,000,000 pdf files (takes 180 Gig space on the disk). My server is a virtual server which has 4 vCPU and 4 Gig RAM, still no problem. The specs you provided is way too high for your needs. You can save billions of files with those servers. Especially if you have SSD. Because even if your indexes do not fit into the memory, swapping will be very fast, you won't even notice a slowdown.