Sharding explained
If you want to build a multi-tenant application, then you set the options.TenantType to define either a SingleLevel or a HierarchicalTenant. This defines the how the tenant's data is organised.
And, by default all the tenant's data is stored in one database, with a DataKey to select each tenant's data. See Multi-tenant explained documentation for an overview of the multi-tenant options.
But if you want use AuthP's sharding feature, then you call the SetupMultiTenantSharding extension method in your AuthP registering. This will add an extra TenantTypes called AddSharding is added, which adds the extra ability for a tenant to store its data in its own database. Adding the AddSharding means you have two approaches to build your multi-tenant app: either Hybrid or Sharding-only (see diagram below to explain these two approaches).
The Hybrid and Sharding-Only approaches have pros and cons which I show in the table below
| What | Hybrid | Sharding-Only |
|---|---|---|
| Summary | Good if you have a large range of small and large tenant data. Use shared db for small tenants and Sharding-Only for large tenants | Best performance and easy to use, but costly if you have lots of cloud databases (consider Azure SQL Database elastic pools ) |
| Feature diffs | "Sign up now" is limited 👎 | Extra Sharding-Only services makes coding easier 👍 |
| Easy of coding | Supporting both tenant types takes a bit more work | Simpler because only one tenant type to code for |
| Easy for admin | It takes two steps to add a new Tenant | It takes one step to add a new Tenant (and obvious) |
| Easy for tenant user | Good | Good |
| Performance | Tenants sharing one database is slower | Best performance |
| Backups | Tenants sharing one database is difficult | Good: each database can be backed up |
The Configuring sharding document details how to select the Hybrid or Sharding-Only approach and explains what each approach (slightly) changes to support the approach you have selected.