Multi-tenancy — many customers served by one application — is the economic engine of SaaS. It is also the decision most expensive to change later. Retrofitting tenancy into a single-tenant codebase is a rewrite wearing a disguise.
The three models
- Shared database, shared schema — every table has a
tenant_id. Cheapest to run, fastest to ship, scales to thousands of small tenants. The default for B2B SaaS. - Shared database, schema-per-tenant — stronger isolation, painful migrations once you pass a few hundred tenants. A middle ground that rarely earns its complexity.
- Database-per-tenant — maximum isolation and per-tenant backup/restore. Right for enterprise or regulated customers who demand it — and for nobody's MVP.
Pragmatic pattern: start shared-schema, and design a clean data-access layer so your biggest enterprise customer can be moved to a dedicated database later without touching business logic.
The four things you must get right on day one
1. Tenant scoping at the data layer. Every query filtered by tenant automatically — middleware or Postgres row-level security — never "remember to add the where clause."
2. Tenant-aware authentication. Users can belong to multiple tenants; invitations, roles, and SSO need the tenant in the token from the start.
3. Per-tenant limits. One customer's runaway import must not slow everyone else — rate limits and job queues keyed by tenant.
4. Billing hooks. Usage metering per tenant is trivial to record from day one and miserable to reconstruct later.
Scaling story
Shared-schema Postgres with sensible indexes comfortably serves millions of rows per tenant. When you outgrow it, the path is read replicas, then partitioning by tenant, then extracting hot tenants — each step incremental if the access layer was clean. This is exactly the architecture work we do in SaaS development engagements, often alongside a cloud migration to right-sized infrastructure.
Building a SaaS and unsure which model fits? Ask us — the answer usually takes one call.
