Multi-Tenant SaaS Architecture: Choosing an Isolation Model

The three models

Shared schema with a tenant column. One database, one set of tables, every row carrying a tenant_id. Simplest to build, cheapest to run, easiest to migrate — one schema change covers everyone.

Schema per tenant. One database, a separate schema per customer. Stronger isolation, but migrations must run across every schema and that gets slow past a few hundred tenants.

Database per tenant. Full isolation, per-tenant backup and restore, straightforward data residency. Most operationally expensive by a distance.

The risk in the shared model

Shared schema means one missing WHERE tenant_id = ? leaks one customer's data to another. That's not a bug you recover from commercially.

The defense is not developer discipline. It's making the correct behavior the default:

Postgres row-level security. Policies enforced by the database, not the application. Set the tenant in the session and the database filters every query. A forgotten clause in application code returns nothing rather than everything — the failure mode you want.

A tenant-scoped data access layer. No raw queries in feature code. Every read goes through something that cannot express a cross-tenant query.

A test that tries to leak. Create two tenants, log in as one, attempt to read the other's records through every endpoint. Run it in CI. It's the cheapest insurance in the codebase.

When to reach for stronger isolation

• Regulatory or contractual isolation requirements — some enterprise deals specify it
• Data residency — an EU customer whose data must stay in the EU is naturally a separate database
• Noisy neighbors — one huge tenant degrading everyone else's performance
• Per-tenant restore — restoring one customer's data from a shared database is genuinely painful

The pragmatic path

Start with shared schema plus row-level security. Design so tenancy is resolved in one place — a middleware that sets tenant context — rather than threaded through every query.

That single decision is what makes later migration feasible. Teams that scatter tenant filtering across hundreds of queries cannot move; teams that centralized it can lift specific tenants into their own databases when a contract requires it, without rewriting the application.

We also see the reverse mistake: starting with database-per-tenant "for enterprise readiness" and drowning in migration overhead across 200 databases before the first enterprise customer signs.

What we build

Shared schema with row-level security, centralized tenant resolution, a cross-tenant leak test in CI, and a documented path to per-tenant isolation for the customers who eventually demand it.