The decision that is hard to undo
Sound familiar?
Your first enterprise prospect asks where their data lives and whether other customers could ever see it. Your answer depends on a database decision made in week one of the project.
Multi-tenancy means one application serving many customers ("tenants") while keeping each one's data separate. How you separate that data drives your hosting cost, your security story, how you handle compliance, and how hard it is to scale. It is one of the few architecture choices that is expensive to change later.
Three ways to separate tenants
| Shared database, shared tables | Schema per tenant | Database per tenant | |
|---|---|---|---|
| How it works | Every row has a tenant ID | Each tenant has its own set of tables in one database | Each tenant has its own database |
| Cost per tenant | Lowest | Low to medium | Highest |
| Isolation | Logical, enforced by queries and row-level security | Stronger: separate tables | Strongest: separate databases |
| Operations | One database to back up, migrate and monitor | Migrations run per schema | Migrations, backups and monitoring per database |
| Noisy neighbours | One busy tenant can slow others | Still shares the database server | Isolated, if on separate resources |
| Best for | Many small and mid-size customers | Hundreds of tenants needing some separation | Few large or regulated customers |
In PostgreSQL, row-level security lets the database itself enforce that each session only sees its own tenant's rows, a strong safety net for the shared model. See the PostgreSQL row security documentation.
How to choose
IfYou expect many small customers and need low running costs
ThenShared database with a tenant ID on every table and row-level security.
IfCustomers need some separation but you have hundreds of them
ThenSchema per tenant, with automated migrations.
IfYou sell to banks, healthcare or government with data residency rules
ThenDatabase per tenant, in the region each customer requires.
IfYou have a mix of small and enterprise customers
ThenA hybrid: shared database by default, dedicated databases as a premium tier.
Want a tenancy model designed for your SaaS?
Get a free consultationWhat AI features change
In 2026, many SaaS products are adding AI features, and those need tenant isolation too. A search index or vector store built for retrieval must be scoped per tenant, so an assistant can never answer one customer's question with another customer's documents. Prompts, logs and any fine-tuning data need the same boundaries.
Treat every AI data store as part of your tenancy model, not an add-on. For AI feature patterns, see AI features that add real value to SaaS.
Tenant isolation checklist
- A tenant ID on every table from the first migration, even if you start with one customer
- Tenant context set once per request and enforced by the database, not only by application code
- Automated tests that try to read another tenant's data and must fail
- Per-tenant rate limits so one customer cannot slow down everyone else
- Backups you can restore for a single tenant without affecting others
- Tenant-aware logging, metrics and billing from the start
- AI search indexes and vector stores partitioned by tenant
Start simple, keep the door open
Most products should start with a shared database and strong tenant isolation, then offer dedicated databases to the customers who need and will pay for them. The key is making every part of the system tenant-aware from day one. We cover the wider journey in SaaS from MVP to scale.
For help designing or building a SaaS platform, see our SaaS development services and enterprise SaaS work.
Key takeaway
Put a tenant ID everywhere, let the database enforce isolation, and include AI data in the same rules. Start shared, and move large or regulated customers to dedicated databases when they need it.
Frequently Asked Questions
Written by
Sachin Patel
Web & SaaS Engineering
