I know this question is similar to other ones. But...

Only that we are switching from 2 very large collections (15Gb in size, constantly growing).

Basically those 2 large collections keep different data for our clients. I'm thinking of creating 2 collections for each client. In terms of size, they will be from 20MB to a few GB each (depending on client size).

Now the pros of having these is that when we loose clients, we need to remove their data. And will be much easier using dropCollection.

The other one is the index, as we keep the client Id on each document in the large collection. And this is not needed, we can remove this index.

About sharding. Now those 2 large ones are sharded across 3 servers. With the small ones, what would be best:

  1. automatically create and shard them when a client comes in (we create collections, add the shard key, all automatically).
  2. only shard the large clients, manually.

What happens if there are lots of small collections (like 10.000, each of 30mb let's say) vs a very large one?

  • 1
    we've ended up with multiple small collections, sharding all of them in a 3 nodes sharded replica set. Will see how it goes Commented Feb 1, 2017 at 14:12
  • 1
    almost 4 years after, I would say this approach was much better in terms of flexibility and how we can deal with data. Commented Jan 6, 2021 at 16:08

1 Answer 1


Multiple small collections will take more space than few big collections. Depending on amount of memory, big collections indexes are more effective than large amount of indexes of small collections.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.