Level 1: namespace isolation (shared everything)

All tenants share one process, one database, one schema. Isolation lives in a TenantId column on every multi-tenant table plus an EF Core query interceptor:

// In DbContext OnModelCreating:
foreach (var entityType in modelBuilder.Model.GetEntityTypes())
{
    if (typeof(ITenantScoped).IsAssignableFrom(entityType.ClrType))
    {
        var param = Expression.Parameter(entityType.ClrType, "e");
        var prop = Expression.Property(param, nameof(ITenantScoped.TenantId));
        var tenantIdValue = Expression.Constant(_tenantContext.CurrentTenantId);
        var filter = Expression.Lambda(
            Expression.Equal(prop, tenantIdValue), param);
        modelBuilder.Entity(entityType.ClrType).HasQueryFilter(filter);
    }
}

When it works: small/mid B2B SaaS up to a couple hundred tenants with similar workloads. Per-tenant cost is pennies a month.

Where it breaks:

• One tenant runs heavy reports — everyone else degrades.
• The query interceptor is missing on a once-a-year code path — data leak between tenants. This will happen if you don't build code-review discipline and isolation autotests.
• A tenant requires regional data residency by regulation (152-FZ for Russian data, GDPR for European).

Level 2: schema-per-tenant (shared infrastructure, isolated data)

One process, one database server, but a separate schema per tenant. EF Core dynamically changes the schema based on request context. In PostgreSQL that's search_path; in SQL Server, a schema prefix on every command.

// Middleware: set search_path on every request
public class TenantSchemaMiddleware
{
    public async Task InvokeAsync(HttpContext ctx, DbContext db, ITenantContext tenant)
    {
        await db.Database.ExecuteSqlRawAsync(
            $"SET LOCAL search_path TO {SanitizeSchema(tenant.SchemaName)};");
        await _next(ctx);
    }
}

When to migrate from Level 1:

• A tenant asks for regulatory data separation (152-FZ vs GDPR).
• One tenant's data hits 100GB+ — indexes stop fitting in the shared buffer pool and everyone suffers.
• You need per-tenant pgvector indexes with different parameters (we see this on RAG workloads).

Price: migrations are now n times more complex. Every Alembic / EF migration runs against every schema. We parallelize the pipeline but the error surface grows.

Level 3: cluster-per-tenant (dedicated infrastructure)

Separate database, separate cache, sometimes a separate application process. Single codebase repository; different runtime instances. Managed via Terraform + a GitHub Actions matrix.

When to migrate from Level 2:

• An enterprise tenant requires 99.95% SLA with an independent blast radius. One failure on shared infra = SLA loss for everyone; a dedicated cluster removes the issue politically and technically.
• Regulation is strict (healthcare with patient data, banking-grade compliance) — the customer wants the option to audit a separate infrastructure.
• On-prem — the tenant hosts at their own facility. That's already cluster-per-tenant in someone else's cloud.

Price: per-tenant cost goes up by 50-100x vs Level 1. Only justified by an enterprise price tag.

Migration triggers between levels

Not knowing in advance which level each tenant will need is normal. What matters is leaving room for the migration. The signals we use:

What you must do at Level 1 to avoid pain later

1. Every table with user data goes through an ITenantScoped interface. No exceptions. A CI audit script verifies that new tables inherit the interface.
2. Query interceptors are centralized. No raw SQL that bypasses EF without explicit TenantId injection and code review.
3. Isolation autotests. Create two tenants, populate data, try to read the other's data via every API — the test must fail. We have 47 of these; they run on every PR.
4. The L1 → L2 migration path is ready from month one. A script "extract tenant data → new schema → switch tenant config → drop source" is written and tested against a synthetic tenant. When a real customer shows up with the requirement, don't panic.
5. Logging with TenantId in every line. Otherwise during an incident you can't separate "it broke for everyone" from "it broke for one tenant who's screaming the loudest."

Where .NET 10 helps

• Improved AsyncLocal performance — we store TenantContext via DI scope + AsyncLocal, and it stopped being a hot path.
• EF Core 10 query filters got smarter with plan cache — previously a per-tenant filter invalidated the plan; now it doesn't.
• Native AOT (where applicable) — for microservices without EF we move to AOT, which cuts per-tenant cost at L1 by another ~30%.

What to take with you

1. Most B2B SaaS should start at Level 1. Don't overcomplicate.
2. The ITenantScoped + isolation-autotest discipline is a non-negotiable contract. Without it Level 1 is a slow-motion landmine.
3. Plan the L1 → L2 migration path from month one. When an enterprise tenant shows up, you'll have 2 weeks, not 3 months.
4. Level 3 is for enterprise pricing only. Never offer "dedicated cluster" as a marketing bonus.