Most architecture decisions are reversible. Tenancy is not one of them. The way you separate one customer's data from another shapes every query, every index and every access check you will ever write — so it is worth slowing down for exactly one afternoon before you commit.
Pick an isolation model on purpose
There is no universally correct answer, only the right trade-off for your stage:
- Shared schema, tenant column — one set of tables with a
tenant_idon every row. Cheapest to run, easiest to migrate, but every query must be tenant-scoped and you lean on row-level security to prevent leaks. - Schema-per-tenant — stronger separation, more operational overhead, harder cross-tenant reporting.
- Database-per-tenant — the strongest isolation, usually reserved for regulated or enterprise customers who require it.
Start simple. Most products are well served by a shared schema with disciplined scoping — as long as the discipline is enforced by the database, not by hope.
Make the database enforce the boundary
The single most common multi-tenant bug is a query that forgets its tenant_id. Do not rely
on every developer remembering:
- Enable row-level security so the database rejects unscoped reads.
- Derive the tenant from the authenticated session, never from client input.
- Add the tenant to your composite indexes so scoped queries stay fast.
Design for the reports you will need later
Cross-tenant analytics (for your own team) and per-tenant analytics (for the customer) pull in opposite directions. Decide early where aggregate data lives so you are not bolting a reporting pipeline onto a schema that fought you the whole way.
Get tenancy right once and it disappears into the background. Get it wrong and it taxes every feature you ship afterwards.
If you are starting a SaaS build, this is exactly the kind of decision we work through with you before writing code — let's talk.
- #saas
- #architecture
- #multi-tenancy
- #postgres
