How many databases can mongodb support?

Hi everyone.

I am building a Saas app and i want to create a Multi tenant model where the clients can create an account and after they can to add users to this account. I was planning to use one database and use a tenantID in each documuent but i need to create backups for each tenant, i am going to work with a lot of optimistic reads/writes and, what i undestood from the mongodb Concurrency, mongodb locks collections not documents and in the future i want to allow to the clients to create their own models with their own fields so if i have one database i am goin to have a lot of collections in one database and this will be a problem.

So i decided to create one database per tenant but i would like to know, how many databases can mongodb support with this vps setup:

4 vCPU Cores
8 GB RAM
200 GB SSD

Each database will have 16-20 collections and documents depends of the client.

Thanks for you support.

Welcome to the MongoDB Community @relb !

The general answer to capacity planning questions like this is that you will have to model your use case to understand resource usage and performance:

WiredTiger, MongoDB’s default storage engine since MongoDB 3.2 (early 2015), has document-level concurrency for most operations. See FAQ: Concurrency for more details.

You’ll have to evaluate whether 8GB RAM is sufficient for your working set and performance expectations, but keep in mind that this will be divided amongst:

  • Your base O/S memory usage.
  • WiredTiger cache for your working set of documents and indexes. With 8GB of RAM the WiredTiger cache will be 3.5GB by default
  • Memory used by the mongod process outside of WiredTiger cache for connections and in-memory data processing (aggregations, in-memory sorts, JavaScript evaluation, …).
  • Any other applications running in the same host environment (ideally only backup, monitoring, and other management agents related to your database deployment).
  • Filesystem cache.

If you are building a self-hosted deployment for production usage, I highly recommend starting with a replica set deployment for data redundancy, high availability, and admin convenience. However, that would require a minimum of three instances rather than one.

Once your multi-tenant SaaS platform has significant adoption you will likely have to consider how to scale and distribute workload. One option would to grow to a sharded cluster deployment for geographic distribution and workload balancing (for example, Segmenting Data by Application or Customer using zone sharding).

As an alternative to managing and scaling a self-hosted deployment, you could also look into MongoDB Atlas which has Auto-Scaling for M10+ dedicated clusters and an Atlas Serverless offering currently in preview with pricing based on resource usage.

Regards,
Stennie

2 Likes

After reviewing the links you provide me, searching and studying my case, I think it is a better option to have only one database and one tenant ID in each document. I have to create a script to backup the tenants and for my custom models I have to create a collection and store all the documents with their own custom json.

If my vps is overloaded, I can use mongodb sharding and apply it to each collection (especially the collection with the custom fields).

Thanks for your help.

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