Choosing the ideal multi-tenancy architecture for an ASP.NET Core application

Question

I am currently working on an application that will be hosted on Azure. As it does not make sense to have an instance of it running for each customer (you'll see why), it's going to be a multi-tenancy solution.

To be honest: I'm only starting to gather experience with web applications, so I apologize if the answer to my question is obvious.

Question: Which multi-tenancy concept will be most beneficial for my application, considering the following assumptions:

• Many tenants (ideally hundreds or even more, we'll see...)
• consisting of few user accounts per tenant (<5-10 in most cases, up to 200 for a hand full of tenants)
• dealing with mostly small amounts of data (<100 entries in <20 tables)
• changes in data occur a few times a day (approx. <50 changes per user per day)
• The application needs to stay responsive (of course)

My thoughts:

1. Database-per-Tenant: Does not make sense as the DB won't be utilized much, therefore not cost effective at all
2. Table-per-Tenant: Could be a good solution, guess this should scale pretty good?
3. Tenant-column within the entities: Could be a problem with scaling, right? Could be better when using charding on the tenant id?

I would really appreciate your help and some "shared experience" in order to choose the not-so-painful path.

Answer 1

A good summary of the different models can be found here:

https://www.linkedin.com/pulse/database-design-multi-tenant-applications-dharmendar-kumar/

Answer 2

Based on my experience on Azure I would recommend CosmosDB with the following options:

• partitioned collections: if tenants are evenly distributed and have similar requirements
• collection per tenant: if some tenants have scale or special requirements
• mix between the preceding two.

Cosmos DB has a lot of benefits e.g sharding, global distribution, performance, freedom of consistency models as well as a good sql support.