A SaaS product serves many customer organizations from one system. Each organization, called a tenant, has its own users, data and settings, and must never see anyone else's. How you separate tenants is one of the first and most lasting technical decisions in a SaaS product. This design is called multi-tenant architecture.
This guide explains the options without jargon, so founders and product owners can take part in the decision.
Why it matters
- Security: a leak between tenants is one of the worst things that can happen to a SaaS business.
- Cost: some models cost much more to run per customer than others.
- Operations: updates, backups and monitoring are easier or harder depending on the model.
- Sales: some customers require their data to be stored separately or in a specific region.
Option 1: Shared tables
All tenants share the same database and the same tables. Every row has a tenant ID, and every query filters by it. This is the most common starting point.
- Pros: lowest cost, simplest to run, one set of updates, easy reporting across tenants.
- Cons: isolation depends on every query filtering correctly. One missed filter can expose data. Very large tenants can affect others' performance.
To make it safe, enforce the tenant filter in one central place in the code rather than in each query, and add database-level protection where available, such as row-level security in PostgreSQL. Test isolation automatically.
Option 2: A schema per tenant
All tenants share one database server, but each has its own set of tables, called a schema. The application switches to the right schema for each request.
- Pros: stronger separation, easier to export or delete one tenant's data, can customize per tenant.
- Cons: updates must run on every schema, which gets slow with thousands of tenants. Reporting across tenants is harder.
Option 3: A database per tenant
Each tenant has its own database, sometimes on its own server. The application connects to the right one for each request.
- Pros: strongest separation, easy to place data in a specific region, one tenant cannot slow others, simple backups and restores per tenant.
- Cons: highest cost, more complex to run and update, harder to report across tenants.
The hybrid approach
Many mature SaaS products mix models: most tenants share tables, while large or regulated customers get their own database as a premium option. This works well if the code treats "where is this tenant's data" as a setting, not an assumption. Designing that boundary early makes the hybrid path easy later.
How to choose
- Many small customers, low price per customer: shared tables.
- Fewer, larger customers with customization needs: schema per tenant can fit.
- Enterprise or regulated customers requiring separation: database per tenant, at least for them.
- Unsure: start with shared tables and a clean tenant boundary, and keep the option to move tenants out.
Identifying the tenant
Each request must be linked to the right tenant. Common ways: a subdomain (acme.yourapp.com), a custom domain, a path or the signed-in user's organization. Whatever you choose, determine the tenant once, early in each request, and make it available everywhere. Never trust a tenant ID sent from the browser without checking the user belongs to it.
Users, roles and permissions
Within each tenant, users need roles: owner, admin, member, read-only. Some products let one person belong to several tenants, such as an accountant with many clients. Plan for that early if it is likely. Sign-in often includes single sign-on for business customers. See user management and authentication.
Files, search and caches
Isolation applies beyond the database. Uploaded files should be stored with tenant-specific paths and access checks. Search indexes, caches and background jobs must all carry the tenant. Leaks often happen in these less obvious places, such as a cache key that forgets the tenant.
AI features in multi-tenant products
If your SaaS adds AI features, such as search over customer documents, the same rules apply. Vector indexes, prompts and logs must be separated by tenant, and the AI must only ever see the current tenant's data. See what is RAG and when do you need it.
Billing and limits
Tenants usually map to billing accounts. Plans set limits, such as users, storage or usage, which the application must enforce per tenant. Track usage per tenant from the start; it is hard to add later. See how to add subscriptions and billing to a SaaS.
Running it
- Monitor performance per tenant, to spot one tenant affecting others.
- Plan backups and the ability to restore one tenant's data.
- Provide data export and deletion per tenant for privacy requests and departing customers.
- Log admin access to tenant data.
Testing isolation
Write automated tests that create two tenants and confirm neither can see the other's data, through every major feature and API. Run them on every change. Include isolation in security reviews and, for higher-risk products, in external penetration tests.
An example
Imagine a platform used by many property companies. It uses shared tables with a tenant ID enforced centrally, database policies as a second layer and file storage split by tenant. When a large customer asks for data in a specific region, the platform can place that tenant in its own database without changing application code, because "where does this tenant's data live" was a setting from the start. This is illustrative. For a real project where every record belongs to a building and access is checked on the server for every request, see our facility management platform case study.
What to do for an MVP
For a first version, shared tables with central tenant filtering and good tests is almost always right. It is cheap and fast to build. Add database-level protection early, and keep the tenant boundary clean so you can move tenants later if customers require it. See how to plan a SaaS MVP.
Per-tenant settings and customization
Customers often want their own logo, colors, email templates, fields or workflows. Store these as settings per tenant rather than as separate code. A settings approach keeps one codebase for everyone, while each tenant sees a product that feels like theirs. Be careful with deep customization for single customers; every special case makes updates and testing harder. Offer a small set of well-designed options instead.
Common mistakes
- Adding the tenant filter by hand in each query.
- Forgetting the tenant in caches, file paths or background jobs.
- Trusting a tenant ID sent from the browser.
- No way to export or delete one tenant's data.
- Building one-off features for single tenants in the shared code.
Checklist
- Isolation model chosen with future customers in mind.
- Tenant identified once per request, never trusted from the browser.
- Tenant filtering automatic, with database-level protection.
- Files, caches, search and jobs all tenant-aware.
- Isolation tests on every change.
- Per-tenant usage, export, deletion and restore.
Whichever model you choose, the most important decision is to treat the tenant boundary as a core part of the design from day one. It protects your customers, and it keeps your options open as the product grows.