Multi-tenant architecture means one running application serves many customers, called tenants, while keeping each tenant's data separate. It is the standard base of SaaS products because every customer shares the same code and infrastructure, which keeps running costs low. The design work lies in isolating tenants from each other.
What is a tenant
A tenant is a customer account that owns its own users and data, such as a company using your product. Employees of tenant A must never see data from tenant B, even though both use the same application and often the same database.
How is it different from single-tenant
In a single-tenant setup, each customer gets their own deployment. That gives strong isolation and easy per-customer customisation, but it multiplies the work: every upgrade, backup and incident repeats per customer.
| Multi-tenant | Single-tenant | |
|---|---|---|
| Infrastructure | Shared | Per customer |
| Running cost per customer | Lower | Higher |
| Upgrades | Once for everyone | Per customer |
| Isolation | By design and access rules | Physical |
| Customisation | Limited, via settings | Wide |
| Fits | Most SaaS | Strict compliance, large bespoke deals |
What database models are there
Teams usually pick one of three:
- Shared database, shared tables. Every row carries a tenant ID. It is the cheapest and simplest to scale, and it relies on every query filtering correctly.
- Shared database, schema per tenant. Each tenant gets its own schema. Isolation is stronger and migrations get heavier as tenants grow in number.
- Database per tenant. The strongest isolation and the highest cost, often used for large or regulated customers.
Many products start with shared tables and move large customers to their own database later.
How do you keep tenants isolated
Enforce isolation in more than one place. Put the tenant ID in every table and every query path, and add database-level controls such as row level security, so a missed filter in application code does not leak data. Test for it explicitly: write tests that try to read another tenant's data and expect failure. A leak between tenants is among the most damaging bugs a SaaS product can have.
What is the noisy neighbour problem
When tenants share resources, one heavy tenant can slow down the others. Plan for it with rate limits, per-tenant quotas, background job queues with fair scheduling and monitoring that shows load per tenant. Moving a heavy customer to dedicated resources is a normal remedy.
What does it mean for compliance
Shared infrastructure raises questions in security reviews. Larger customers often ask where their data lives, how it is separated and who can access it. Decide early whether you can offer regional hosting, such as EU data residency, or a dedicated deployment for customers who require it. Retrofitting that into a design built around shared tables takes real effort.
What this means for your engineering team
Tenancy is hard to change once data exists, so the decision deserves a senior engineer's time at the start. AI coding agents can generate queries quickly, and they will happily forget a tenant filter, so isolation tests and database-level controls matter more when agents write code. See how to review AI-generated code for the review habits that catch this.
Backend platforms such as Supabase offer row level security that suits shared-table tenancy. Our vetting puts candidates in a real codebase for two sixty-minute sessions, one with AI tools off and one with their own agents on. To add senior capacity to a SaaS team, see backend engineers, from €5,600 a month for a full-time engineer.
Short answers
Is multi-tenancy the same as SaaS?
Not exactly. Most SaaS products use multi-tenancy because it lowers cost, but a SaaS product can also run a separate deployment per customer.
Which multi-tenant database model is best?
Shared tables with a tenant ID is simplest and cheapest. Schema or database per tenant gives stronger isolation at higher cost.
How do you prevent data leaking between tenants?
Filter by tenant everywhere, add database-level controls such as row level security, and write tests that try to cross tenant boundaries.
Can I move from single-tenant to multi-tenant later?
Yes, but it is a large change to data models and access control, so decide early if you can.
