1 serverless instance per tenant in a multi-tenant app?

MongoDB Atlas
1

Hi there,

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:

  1. logic to auto-provision new projects
  2. manage the sharding of tenants across instance/project
  3. 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.

Big thanks!

2

(Correctly tagging @derjanni @Vishal_Dhiman - much appreciated if you have any additional conclusions or context to share after the prior thread - thanks!)

3

The outcome was pretty simple, it’s not possible. For us this was just one of the reasons why we did not proceed with Mongo. What we did as a prototype is that we’ve written the provisioning of tenants onto 25 serverless instances with 50 dbs each. To be honest: that’s an ugly hack.

If you need to avoid noisy neighbours and have an architectual reason why you cannot pool tenants in collections, databases or instances (which there are numerous reasons for), then Mongo serverless is probably not for you.

We have abandoned our prototype and moved on with MySQL8 (AWS Aurora Serverless V2). Again, this restriction wasn’t the main reason, there were others where Mongo did not fit our use case.

4

@derjanni disappointing to hear, but very useful to know. thanks for taking the time to share your experience. fingers crossed for this to change in the future!

1 Like