A schema per organization, when you need one

Every tenant-scoped row carries its organization, every query is filtered to the current one, and a write to another organization's row is refused. For most products that is the right isolation: one database, simple reports, cheap operations.

When the shared database is not enough

Some customers ask for their data to live apart physically. Set Tenancy:Mode to SchemaPerTenant and register your product's context with AddColdenTenantDbContext: each organization gets its own schema, created when the organization is created and migrated by migrate, while the kit's own tables stay shared.

The query filters stay in force in both modes, so a tenant's rows are apart twice.

The tenancy guide has the details and the limits, such as one connection pool per organization.