Multi-Tenant SaaS Architecture in Plain Terms
By CodexierPublished 6 min read
When several companies use the same SaaS product, their data has to be kept apart while the code stays the same. How you do that is the tenancy model, and it is one of the few architecture decisions that is expensive to change later. This guide explains the two main models without the jargon, what each costs to run, what each lets you promise a security-conscious buyer, and how to keep the door open to switching.
What a tenant is
In practice a tenant is a row in an organisations table, and every other record points to it. Users belong to a tenant, and a user may belong to several if your product supports agencies or consultants. The tenant id is the key that every query, every file path and every background job must carry. Forgetting it once is how one customer sees another's data, which is the failure a SaaS company cannot afford.
Separate databases per customer
In the isolated model each tenant gets its own database, or at least its own schema. Nothing is shared, so a bug in one query cannot leak across customers, a backup is per customer, and a customer can be placed in a specific region or even on their own server. This is what large or regulated buyers often mean when they ask for 'isolation'.
| Aspect | Shared with row-level security | Database per tenant |
|---|---|---|
| Running cost | One database; grows with total load | One database each; cost grows with customer count |
| Operations | One migration, one backup job | Migrations and backups repeated per tenant; needs automation |
| Isolation guarantee | Logical, enforced by policies | Physical, auditable by the customer |
| Per-customer region or restore | Hard | Straightforward |
| Onboarding a new customer | Insert a row | Provision a database |
| Fits | Most products, especially early | Enterprise, healthcare, public sector, very large tenants |
Security and cost trade-offs
The shared model is not less secure in principle; row-level security enforced by the database is a strong guarantee. It is less legible to a buyer's security team, who cannot inspect your policies and would rather hear that their data sits in its own database. The isolated model turns that conversation into a yes, at the cost of running hundreds of databases as the customer base grows. Cost per customer therefore favours shared; deal size favours isolated. Many companies end up with both: shared for the standard plan, isolated as an enterprise add-on.
Data residency
Isolated databases can be placed per region. In the shared model, residency is per product, so choose an EU region for the whole thing; see our note on GDPR for SaaS founders.
Performance
Shared needs per-tenant limits to stop one heavy customer degrading everyone. Isolated needs capacity planning per database instead.
Backups and restore
Restoring a single tenant is the operation customers ask about after an accidental bulk delete. Plan for it in the shared model with point-in-time exports per tenant.
Changing the model later
Moving from shared to isolated is feasible if the tenant id is on every table and all access goes through one data layer; you copy a tenant's rows to a new database and point that tenant's connection at it. Moving from isolated to shared is harder, because ids collide and tables must be merged. Moving from a design with no tenant concept to either is a rewrite. That is why the decision belongs in the planning phase, which is what our MVP planning blueprint covers before any code is written.
When you do not need to think about this: an internal tool for one company has one tenant and needs none of it. A consumer app where each user's data is private has users, not tenants, and row-level security per user does the job. If you are building B2B software for more than one customer organisation, the decision is unavoidable; book a free 15-minute call if you want to talk it through against your customer list, or read our SaaS and MVP overview first.
Frequently asked questions
Which model should an MVP start with?
Shared database with row-level security, in almost every case. It is cheapest to run, simplest to operate and sufficient for most customers. The condition is discipline: a tenant id on every table from the first migration.
Is a shared database GDPR-compliant?
Yes. The GDPR requires appropriate technical measures, not physical separation. Row-level security, encryption and access logging meet that for the vast majority of products. Some customers may still contractually require isolation, which is a commercial question.
Can one customer slow down the others?
In the shared model, yes, if a tenant runs heavy reports or imports without limits. Per-tenant rate limits, query timeouts and background job queues are the standard answer, and they are needed early rather than late.
What does isolation cost per customer?
Each isolated database has a fixed monthly cost even when idle, plus the operational cost of running migrations and backups across all of them. The usual answer is to charge for it as an enterprise feature rather than absorb it.
Deciding how your customers' data should live?
Tell us who your first customers are and what they will ask for. In fifteen minutes we tell you which tenancy model fits, and what to build now so the other one stays possible.
Book a free 15-minute call