Key takeaways
- Most B2B products should start with a shared database and row-level isolation.
- Move specific tenants to dedicated schemas or databases when compliance or size requires it.
- Enforce tenant context in the data layer, not only in application code.
- Design exports and backups per tenant from the start.
Tenancy is one of the most expensive decisions to reverse in a SaaS product. A practical comparison of the three common models and the signals that should drive the choice.
The three common models
Multi-tenant systems usually use one of three approaches, each trading isolation against operational cost.
- Shared database, shared tables: every row carries a tenant identifier. Cheapest to run, simplest to deploy, weakest isolation by default.
- Shared database, schema per tenant: tables are duplicated per tenant inside one database. Better isolation, more complex migrations.
- Database per tenant: strongest isolation and easiest per-tenant backup, highest operational cost.
A sensible default
For most early B2B products, shared tables with a tenant identifier on every row is the right starting point. It keeps infrastructure simple and makes cross-tenant operations — billing, analytics, support — straightforward.
The risk is data leakage through a missing filter. Mitigate it in the database, not only in code: PostgreSQL row-level security policies, for example, can enforce that every query is scoped to the current tenant even if a developer forgets.
Signals that you need more isolation
Stronger isolation becomes worthwhile when specific conditions appear. It rarely needs to apply to every tenant.
- An enterprise customer contractually requires dedicated storage.
- Regulation requires data residency in a specific region.
- A single tenant's volume affects performance for others.
- Customers need independent backup and restore.
Plan for a hybrid
The most practical long-term design supports more than one model: most tenants share infrastructure, while a few large or regulated tenants get dedicated databases. That is only possible if tenant resolution happens in one place — typically a routing layer that maps each request to the right connection.
Build that routing layer early, even if it always returns the same database at first. It is a small cost now and a large saving later.
Operational details that matter
Tenancy affects more than the schema. Rate limits, background jobs, file storage paths, caches and logs all need tenant context. So do customer-facing features like data export and account deletion, which enterprise buyers will ask about during procurement.
Enjoyed this? Get the next one by email.