System design · interactive

Multi-tenancy

A SaaS app serves many companies from one system. Their data can share tables, get a schema each, or a database each. The choice decides cost, isolation, and what happens when a developer forgets a WHERE tenant_id clause.

logged in as acme

SELECT * FROM invoices;  -- forgot tenant filter

Acme invoice #12
Acme invoice #13
Globex invoice #7 (another customer!)
Initech invoice #3 (another customer!)

Isolation: ●○○
Cost per tenant: cents
Migrations: one migration
Noisy neighbours: high

One missing WHERE clause and acme sees every customer's invoices. With shared tables, isolation depends on every query being right.

Model

Developer forgets the filter

Row-level security

Step 1 of 4 · read left to right

1
Shared tables: cheapest, riskiest
Every row has tenant_id. One schema to migrate, thousands of tenants per database.
Enforce it in one place: RLS or a data layer.
2
Schema or database per tenant
Stronger isolation and easy per-tenant backups, but thousands of schemas or databases to migrate and monitor.
Common for enterprise customers.
3
Noisy neighbours and limits
One big tenant can slow everyone. Per-tenant rate limits and quotas, or moving them to their own shard.
Tag metrics and logs with tenant id.
4
Mix models by tier
Small customers share; large or regulated ones get dedicated resources. Route by tenant at the edge.
Design for moving tenants between them.

In production

Tools and technologies

SaaS platforms choose a tenancy model early.

Not tied to one language — use these names when you search docs or design a system.