Maximum number of Collections

MongoDB Atlas
,
1

Hi,

We are building a multi-tenanted system and planning to have a collection per tenant.

Is there a maximum number of collections that can exist in a database? we are planning on using MongoDB atlas so therefore I want to know whether this limit applies to that mainly.

Thank you,
Dushan

3 Likes
2

Hey @dushan_Silva,

I don’t think it’s a good idea. Why not use just one collection and a field tenant with an index on it to support your queries?

One collection = at least one index (_id) and 2 files. One for the index and one for the collection (with the WiredTiger engine). More than 10K collection is usually not a good news for your file system.

Having a lot of collections is an anti-pattern:

https://www.mongodb.com/article/schema-design-anti-pattern-massive-number-collections

Just like an array in a document should be bounded, the number of collections should also be limited. 10 collections with 10 documents each isn’t the same as 100 documents in 1 collection. The later is more optimal.

Cheers,
Maxime.

1 Like
3

Hi @MaBeuLux88,
Thanks for the reply,
Yes, I do understand the stress on the file system, while having a field called tenant is a valid option I did not think about texting that filed so thanks for that :), I was looking at the [1], which mentions about database per tenant or collection per tenant as a valid option if we are building large scale multi-tenant application. Are the ideas presented in this presentation not applicable in the new engine?

[1] - Cloud Architecture: A Comprehensive Guide | MongoDB

Thanks
Dushan

4

Hey @dushan_Silva,

I just listened to this presentation and even if it’s from 2017, everything in it still applies I think. I didn’t hear anything that was clearly outdated. All the pros and cons Justin mentions for each strategy are still valid.

Cheers,
Maxime.

1 Like
5

Hi @dushan_Silva,

Each multi-tenant strategy has pros and cons. Targeting large scale multi-tenant use cases might mean having a small number of tenants that are very large, or a large number of tenants that are very small, or anything in-between. My recommendation is to consider growth over time. It’s difficult to assess but things like customer onboarding, operational overhead, and cost per customer are all important considerations.

Imagine having a collection per tenant. Onboarding customers becomes cumbersome because collections and indexes must be created appropriately and (ideally) automated. Any changes to indexes would need application to every existing collection per tenant. And there are more considerations. But the additional overhead doesn’t matter much for a small number of tenants.

Most organizations want a single collection where sharding can provide scale. I don’t know if that applies here, but most customers succeed with this approach.

I hope this helps!

Justin

1 Like
6

Thank you justin :slight_smile: your input is much appreciated

7

This topic was automatically closed 5 days after the last reply. New replies are no longer allowed.