Multi tenant architecture means one running SaaS application serves many customers (tenants) while keeping each one's data separate. For most US-based B2B products, start with a shared database and tenant-scoped access, move large or regulated tenants to their own schema or database, and handle customization through an extension layer rather than per-customer code branches.
Key takeaways
- Tenancy is a spectrum: shared database, schema per tenant and database per tenant trade cost against isolation, and most mature products mix them.
- Isolation is enforced in code: a tenant ID column alone is not protection; trusted tenant context must travel with every request.
- Noisy neighbours are a capacity problem: quotas, rate limits and tiered pools contain them better than bigger servers.
- Residency drives placement: regional deployments and per-tenant location settings matter more than the data model itself.
- Never fork per customer: keep one core and put tenant-specific behaviour in configuration and a governed extension layer.
Multi-tenant models at a glance
| Model | What is shared | Isolation | Cost profile | Best fit |
|---|---|---|---|---|
| Shared database, shared schema | Everything; rows carry a tenant ID | Logical only | Lowest per tenant | Many small tenants |
| Schema per tenant | One database server, separate schemas | Moderate | Medium; migrations multiply | Mid-size tenants, custom fields |
| Database per tenant | Application tier only | Strong | Highest; scales with tenant count | Regulated or very large tenants |
| Hybrid (pool plus silo) | Pool for most, dedicated for a few | Mixed by tier | Balanced | Products with a premium enterprise tier |
What is multi-tenant architecture?
Multi-tenant architecture is a design where a single application instance serves multiple customers, each isolated from the others. In single-tenant design, every customer gets an independent instance. Multi-tenancy trades some isolation for lower cost and simpler operations.
The Harvard enterprise architecture guidance on SaaS tenancy describes these same two primary designs from the vendor's perspective. The practical difference is operational: with one shared application you ship one release, patch once and monitor one system.
The catch is that every shortcut in isolation becomes a risk shared by every customer. That is why the data model is only the first decision of several.
The three data models
Shared database, shared schema
All tenants live in the same tables, and each row has a tenant identifier. It is the cheapest to run and the easiest to migrate, since one schema change covers everyone. The weakness is that one missing filter in a query can leak data across tenants.
Schema per tenant
Each tenant gets its own schema inside a shared database server. You get cleaner separation and room for tenant-specific columns or tables. The cost shows up in migrations: a change must be applied to every schema, and tooling has to track which tenants are on which version.
Database per tenant
Each tenant gets a dedicated database. Isolation is strongest, backups and restores are per customer, and you can place a database in a chosen region. You pay for it in cost that scales with tenant count, including for idle tenants.
Silo, pool and bridge
Architects often name these as silo (dedicated), pool (shared) and bridge (a mix). Bridge is where many products land: a pool for the long tail and silos for the few customers whose contracts demand it.
How should you choose a tenancy model?
Choose by tenant size, compliance needs and price tier. Use a shared pool when you have many small tenants and no contractual isolation demands. Use dedicated schemas or databases for regulated, security-sensitive or very large customers. Plan for a hybrid from the start so a tenant can move later.
Here is the rule I would apply. Default to the pool. Promote a tenant to a silo only when a contract, a regulator or measured load requires it, and charge for it. Teams that go database-per-tenant for everyone on day one usually pay for it in operations before they have the revenue to justify it.
Whether a pooled design is safe enough for your sector is a judgment call your security and legal teams must make; this guide cannot settle it for you.
How do you keep tenants isolated?
Isolation comes from enforcing tenant context on every request, not from the database layout alone. Resolve the tenant from the authenticated session, pass it through every service call, and apply it automatically in the data layer, using row-level security where your database supports it.
A tenant ID column is a start, not a control. Query helpers that add the filter by default, tests that try cross-tenant reads, and separate encryption keys for sensitive tenants all reduce reliance on every developer remembering a WHERE clause.
Access rules inside a tenant matter too. Our guide on RBAC vs ABAC for multi-tenant SaaS covers how to model who can see what once the tenant boundary is secure.
What is the noisy neighbour problem?
The noisy neighbour problem happens when one tenant's heavy usage consumes shared resources and slows everyone else. It is most common in pooled designs, where tenants share compute, connections and storage. Fix it with per-tenant quotas, rate limits and moving heavy tenants to dedicated capacity.
Start by measuring usage per tenant: queries, API calls, background jobs and storage. Without that data you cannot tell a noisy tenant from a bad release.
- Rate limits: cap API calls per tenant, with higher ceilings on higher plans.
- Queue fairness: give each tenant its own share of background workers so one bulk import cannot starve others.
- Query guards: timeouts and row caps on reports and exports.
- Tiered pools: move the heaviest tenants to a separate pool or silo.
I will not quote latency numbers here, because they depend entirely on your stack and workload. Measure your own.
How does data residency affect tenancy?
Data residency requires that a tenant's data be stored in a specific country or region. Multi-tenant products meet it by running separate regional deployments and assigning each tenant a home region at signup, so the data and its backups stay put.
A single global pool cannot do this. Many teams run the same application in several regions, each with its own pool, and route tenants by a region setting. Database-per-tenant makes placement easy, but regional pools work too.
Check what else leaves the region: logs, search indexes, analytics copies, AI model calls and support tooling. Residency fails more often in these side channels than in the primary database. Rules differ by country and contract, so confirm requirements with counsel before promising anything.
Per-tenant customization without forking the product
You customize per tenant without forking by keeping one codebase and layering tenant-specific behaviour on top: configuration for settings, and a governed extension layer for new dashboards, workflows and forms. Each extension runs in isolation and is scoped to its tenant.
Forking, meaning a branch or deployment per customer, is the failure mode. Every fork needs its own upgrades, tests and fixes, and it quietly turns multi-tenant SaaS back into many single-tenant products.
Three layers that scale
- Configuration: custom fields, permissions, approval rules. Cheap, but it only changes existing behaviour.
- Extension layer: tenant-scoped capabilities that add behaviour the core never had, without touching core code.
- Dedicated infrastructure: a silo for isolation or residency, running the same code as everyone else.
Academic work on event-based customization of multi-tenant SaaS, published through PubMed Central, describes a non-intrusive approach that customizes per tenant while limiting extra API calls to the main product. The principle is the same: extend from outside the core.
This is where Vezel fits. It is an embedded AI extension platform: you connect your APIs, customers generate dashboards, workflows, reports and forms from plain English, and extensions run in a secure container.
They inherit your existing authentication, permissions and access controls, so the tenant boundary you built still applies. Most SaaS platforms can integrate it in a few days. For the mechanics, see how to inherit row-level permissions in SaaS tools, and for lifecycle, publishing and versioning extensions.
Open question: how much tenant-built logic should run in a shared pool versus a silo? There is no settled answer; governance and per-tenant limits are what make either workable.
Checklist before you commit
- List tenant segments by size, compliance needs and expected load.
- Pick a default model and a promotion path to dedicated resources.
- Enforce tenant context in the data layer, and test cross-tenant access.
- Meter usage per tenant and set quotas.
- Map every place data is stored, including logs and backups, against residency needs.
- Ban per-customer branches; route variation through configuration and extensions.
FAQ
Is shared database multi-tenancy secure?
It can be, if tenant context is enforced automatically and tested. It is less forgiving than separate databases, so regulated customers often require stronger isolation.
Can I change tenancy models later?
Yes, but it is painful. Design tenant identifiers and data access so a tenant can be exported and moved to a dedicated schema or database.
Does multi-tenancy limit customization?
Only if customization means editing core code. An extension layer keeps one product while giving each tenant its own capabilities.
If your tenancy model is sound but enterprise customers keep asking for tenant-specific dashboards and workflows, book a Vezel demo to see extensions that inherit your permissions and run without forking. You can also review how it works first.
