I have essentially the same question as derjanni posted here: How many serverless instances can I have in a project? - specifically a multi-tenant SaaS application wishing to create a serverless instance for each tenant.
(For my use-case: each tenant has unique data structures → hence unique collections per tenant rather than a multi-tenant model using shared collections with a
tenant_id index. Another factor is desire for maximum separation of data between tenants for security of sensitive data.)
I note the guidance provided by Vishal_Dhiman in that thread before the mention of a possible offline discussion:
For serverless, here are the current limits:
Max number of instances per project - 25
Max number of databases per instance - 50
So in total you can have 25x50=1250 databases per project. You can also create many projects per organization. To get to 5000, you can create 4 projects.
I’m curious where this discussion ended - in general is there a more flexible approach possible to 1 serverless instance per tenant than having to shard across 50 databases/instance → 25 instances/project → N projects?
For the near future, the greatest undesirable overhead of the shard-across-projects model would be the need to build/manage all the following:
- logic to auto-provision new projects
- manage the sharding of tenants across instance/project
- automating the provisioning of a database and database-user pair for each tenant, to limit access appropriately
…vs. a model of 1 serverless instance per tenant would dramatically simplify things, potentially eliminating all 3 of the above requirements in favour of a single instance-per-tenant provisioning model.
The theoretical max capacity is also a future concern given the application intent is to support a self-serve freemium model (max 1250 databases/project x 250 projects/organisation → max ~312,500 tenants).
Appreciate if any further guidance can be shared on where this discussion ended - or recommendations for this model in general.