Multi-Tenant Architecture for SaaS

Multi-tenancy mistakes show up late, when a query leaks data, a migration locks every customer, or billing cannot attribute usage per account.

These patterns reflect what we implement for B2B SaaS where isolation and operability both matter.

Choose tenancy at the data layer first

Shared database with tenant_id on every row is the default for early SaaS, simplest ops, lowest cost. Enforce tenant scope in the ORM or query layer, never only in the UI.

Separate schemas or databases per tenant make sense for enterprise contracts with strict isolation requirements, at the cost of migration and backup complexity.

Authn, authz, and admin impersonation

Separate authentication (who you are) from authorisation (what you can touch). Role checks belong on the server for every mutation.

Support impersonation for customer success with audit logs, who impersonated whom, when, and what changed. Never share super-admin passwords.

Migrations and background jobs

Run migrations in ways that do not require simultaneous downtime for all tenants. Prefer additive schema changes and backfills over destructive alters during peak hours.

Tag background jobs with tenant_id and rate-limit per tenant so one noisy customer cannot exhaust shared workers.