Yeah, this is for sure not a good approach - Mongo has a hard 24000 limit for namespaces (you’re a way off yet!) but before you get close to that limit, you’ll start having performance issues with the number of collections.
There are two schools of thought for this:
- move to a single tenant environment (every customer gets their own DB)
- move to a single collection per “collection” and have a companyId or similar indexed. I’m a little intrigued about how you got meteor to play nice with 1 collection per customer, as it doesn’t generally like this!
Which of these you choose will likely depend on your business plan and the size of your customers - single tenant is easy to reason about, but it gets quite complicated to maintain 1 deployment per customer. Multi tenant with a single collection is easier for devops, but you have to be absolutely sure your code doesn’t leak information between customers.
Unless you choose to go single tenant, I’d just start with merging all those collections (assuming the schema is the same across them all) - no need to split out the collections horizontally 1:1 mappings between collections are rare - and so long as your documents aren’t close to the 16MB cap, there aren’t a lot of advantages to splitting out (there are some, but they’re pretty specific).
The errors you’re seeing can likely be resolved by adding appropriate indexes, if you’re using Atlas you get a profiler for free that will tell you which queries are ran most frequently, which are slow, and which do/don’t use indexes.