Multi-tenancy in SaaS: three isolation models and when each makes sense

"Multi-tenant" describes any platform that serves many organisations from one codebase. How their data is separated is the decision that matters, and it is hard to change later.

Model 1: shared tables with a tenant column

Every row carries a tenant_id. Cheapest to run, simplest to deploy, and every query must be scoped correctly — one missed filter is a data leak. Works well when tenants are many and small, and when the application layer enforces scoping centrally rather than in each query.

Model 2: schema per tenant

One database, one schema (or table prefix) per tenant. Stronger isolation and easier per-tenant backup or export, at the cost of migrations that run once per tenant and connection handling that switches context. A good middle ground for a few hundred tenants with meaningful data.

Model 3: database per tenant

Complete isolation, straightforward compliance answers, and the ability to place a tenant on its own server. Operationally heaviest: provisioning, monitoring and upgrades all multiply. Justified for regulated or very large tenants.

Choosing

• Start with the question a tenant will ask: "can another customer ever see my data?" — and how you will prove the answer.
• Decide what a tenant export or deletion looks like before choosing.
• Whichever model you pick, put tenant resolution in one place in the code and test it deliberately.