Guide · Updated October 2026
Multi-tenancy is one decision that shapes many others: how data is isolated, how customers sign in, how they are billed, and how your own team supports them. These are the choices worth making deliberately, and early.
1. How tenant data is isolated
| Shared schema | Schema per tenant | Database per tenant | |
|---|---|---|---|
| How it works | One set of tables, a tenant ID on every row, row-level security | One database, a separate schema for each tenant | A separate database for each tenant |
| Isolation | Logical, enforced by policy | Stronger | Strongest |
| Operating cost | Lowest | Grows with tenant count; migrations run per schema | Highest |
| Noisy neighbours | Most exposed | Partly contained | Contained |
| Suits | Many small tenants | Fewer, larger tenants or stricter isolation | Enterprise or regulated tenants with contractual isolation |
Whichever you choose, enforce it in more than one place. Tenant scoping in middleware and query helpers catches mistakes in application code. Row-level security in the database catches the ones that get past it.
2. Identity and single sign-on
Decide early whether a person can belong to more than one tenant, because it changes the data model. Business customers will ask for single sign-on through SAML or OIDC, and larger ones for SCIM provisioning. It is far easier to design for these than to add them under a sales deadline.
3. Roles and permissions
Start with roles, and expect to need finer rules later. Check permissions at the API boundary and again at the data layer, so a missed check in one place is not a breach. Keep an audit trail of who did what, in which tenant.
4. Billing
Plans, seats, and usage sound simple until the first plan change mid-cycle. The parts that cause trouble are proration, failed payments, usage events that arrive twice, and records that drift from the billing provider. Make usage events idempotent, and reconcile against the provider's webhooks.
5. The admin surface
Your own team needs to run the product: see what a customer sees, change a plan, switch a feature on for one tenant, and answer a billing question. Build these tools inside the product, behind admin authorisation, with impersonation recorded in the audit log.
6. Operating per tenant
- Label logs and metrics with the tenant, so one customer's problem can be found.
- Apply rate limits per tenant.
- Be able to export or delete one tenant's data on request.
- Know how you would restore one tenant without touching the others.
Common mistakes
- Adding tenant isolation after launch.
- Relying on application code alone to keep tenants apart.
- A billing integration with no reconciliation.
- No way for support to see what a customer sees.
- Migrations written as if there were only one schema.
How we build it at TechMaven
We run four SaaS products of our own on this kind of stack: SmileQute, HRMSuite, RaceProOnline, and StaySynq. We implement both shared-schema with PostgreSQL row-level security and schema-per-tenant, chosen for the workload. Permission checks live at the API boundary and the database layer. Billing integrations include usage metering with idempotency keys and webhook reconciliation, and internal tools are built in the same codebase behind admin authorisation.
More on how we work is on the SaaS products page.