Separate databases give the strongest boundary at the highest operating cost, separate schemas sit in the middle, and shared tables are cheapest but depend most on correct policies and tests. Choose by your security needs, compliance needs and operational capacity, and document which boundary each data class uses.
The options compared
The OWASP Multi-Tenant Security Cheat Sheet lists the strategies and what each needs to be strong.
| Model | Boundary | What it requires | Cost |
|---|---|---|---|
| Separate databases | Database and credential boundary | Isolated credentials, network access, admin paths and backups | Higher operational cost |
| Separate schemas | Namespace and database-role boundary | Disciplined grants, role separation, search_path handling, migrations | Medium |
| Shared tables, row level | Policy and row boundary | Enforceable tenant ownership, policy coverage on every tenant table, constrained request roles, negative-path tests | Lowest infrastructure cost |
| Hybrid | Varies by workload or tier | Document and test the boundary per data class | Mixed |
Notice the pattern: each stronger boundary moves the guarantee out of application code and into infrastructure.
What each model really protects against
Separate databases. A bug in a query cannot reach another tenant's data because the connection cannot see it. The sheet adds the condition that this is strong when credentials, network access, administrative paths and backups are isolated. If one admin credential opens every database, the boundary is weaker than it looks.
Separate schemas. Isolation depends on grants. If an application role can read every schema, the namespace is cosmetic. Migrations multiply, since each change must run per schema.
Shared tables. One mistaken query can return everyone's rows. Database row-level security and tenant-scoped repositories reduce the risk, and the sheet treats application-level ORM filters as defense in depth, not complete enforcement, because raw SQL and bulk operations can bypass them.
How to choose
- List the sensitive data classes. Not everything needs the same boundary.
- Ask who requires what. Some customers or regulations may expect stronger separation, and the answer should come from the contract or the rule, not a guess.
- Count your tenants. Thousands of small tenants make per-database models costly to run and migrate.
- Check your operations. Can you run migrations across many schemas or databases reliably?
- Pick per tier if needed. A hybrid, with shared tables for small tenants and dedicated databases for those who need it, is a recognised pattern, provided you document and test each boundary.
- Decide how you will prove it. Whatever you choose, plan a test that fails when the boundary breaks.
Common mistakes
- Choosing shared tables, then adding tables without policies.
- Choosing schemas, then using one broad application role.
- Using a superuser or bypass role for normal request paths.
- Forgetting caches, queues and object storage, which need tenant separation too.
- Taking a single shared backup and having no safe way to restore one tenant.
Proof beats claims
When a buyer asks how data is separated, a clear answer names the boundary, the role used at runtime and the test that checks it. For shared tables that means policies on every tenant table, a request role without bypass rights and tests run through the same pool as production.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how an inventory lists the database drivers and ORMs that sit behind your isolation choice.
Safeguard offers SBOM and dependency scanning, with a free scan at gold.safeguard.sh/scan.
Quick check
Is database per tenant always safest?
It has the strongest boundary only when credentials, network paths, admin access and backups are separated too. One shared admin credential weakens it.
Can I mix models?
Yes. The OWASP sheet lists a hybrid approach. Document and test the boundary for each data class.
Sources
Last reviewed: 19 October 2026.
