Multi-tenancy is the defining constraint of a SaaS backend: many customers share the same running system while their data must stay perfectly separate. The isolation model you pick shapes cost, operational load, compliance posture and how a cross-tenant leak becomes possible. It is worth deciding deliberately, because it is the hardest thing to change later.
Pick an isolation model with eyes open
The spectrum runs from a shared schema with a tenant id column, through a schema per tenant, to a full database per tenant. Shared schema is cheapest to run and hardest to keep leak-proof; database-per-tenant is the strongest isolation and the heaviest to operate at scale. Most products land on shared schema early and peel the largest or most regulated tenants out to their own database when the requirement appears.
- Shared schema: lowest cost, simplest ops, strictest discipline needed on every query.
- Schema per tenant: cleaner separation, more migration and connection overhead.
- Database per tenant: strongest isolation and compliance story, highest operational cost.
Make tenant scoping impossible to forget
In a shared-schema model, one query that forgets its tenant filter is a data breach. Do not rely on every developer remembering — enforce scoping structurally, whether through Postgres row-level security, a data-access layer that injects the tenant on every query, or both. The goal is that the unscoped query is the one that is hard to write, not the easy default.
Plan for noisy neighbours and per-tenant limits
Shared infrastructure means one tenant's heavy month can degrade everyone else's latency. Rate-limit and quota per tenant, watch per-tenant resource use, and be ready to move a large account to dedicated capacity before it starts hurting its neighbours. Onboarding, migrations and backups also have to work per tenant — a schema change now runs across every tenant at once, so migrations must be backward compatible and rolled out carefully.
- Enforce per-tenant rate limits and quotas so one account cannot starve the rest.
- Track usage per tenant to spot noisy neighbours before customers complain.
- Keep migrations backward compatible; you cannot update every tenant in a single instant.