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.
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.
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).