Database Multi-Tenancy Patterns: Shared Schema vs. Database per Tenant
Compare the main multi-tenancy patterns — shared schema with row-level security vs. a database per tenant — and how to choose for your SaaS on PostgreSQL.
Every SaaS has to answer one architectural question early: how do you keep tenants' data separate? Get it wrong and you face data leaks, noisy-neighbor problems, or painful migrations later. There are three common patterns on PostgreSQL — here's how they compare.
1. Shared schema, row-level security
All tenants share the same tables; an org_id column plus row-level security
isolates them.
create policy "tenant isolation"
on invoices for select
using (org_id = auth.org_id());
- Pros: Simplest to operate, cheapest, easy cross-tenant analytics.
- Cons: Isolation depends on correct policies; one bad query path is a risk; noisy neighbors share resources.
- Best for: Most early-stage SaaS with many small tenants.
See the RLS guide for how to enforce this safely.
2. Schema per tenant
Each tenant gets its own PostgreSQL schema within a shared database.
- Pros: Stronger logical separation; per-tenant customization is possible.
- Cons: Schema sprawl; migrations must run across many schemas; connection and tooling complexity.
- Best for: A moderate number of tenants needing more isolation than a shared schema.
3. Database per tenant
Each tenant gets a dedicated PostgreSQL database.
- Pros: Strongest isolation; per-tenant backups, scaling, and even residency; no risk of cross-tenant leakage by query.
- Cons: Most operational overhead at very high tenant counts; cross-tenant reporting is harder.
- Best for: Fewer, larger, or compliance-sensitive tenants — and platforms built around isolation from the start.
How to choose
| Priority | Lean toward |
|---|---|
| Lowest cost, many small tenants | Shared schema + RLS |
| Stronger isolation, moderate scale | Schema per tenant |
| Maximum isolation / compliance | Database per tenant |
Many platforms blend these — for example, a dedicated database per project plus row-level security inside it for per-user rules. That's the model Kolaybase uses: each project gets its own PostgreSQL database, and you still apply RLS within it. It's why the backend for SaaS applications starts isolated by default.
Pick the pattern that matches your tenant count and isolation needs today — and prefer one you can evolve without a rewrite.
Keep reading
- Self-Hosting Your Backend with Docker: What to Know
Why and how teams self-host their backend with Docker Compose — data residency, cost control, and no vendor lock-in — plus the trade-offs to plan for.
- How to Choose a Backend for Your AI App
AI apps still need a normal backend: users, conversation history, document storage, and usage limits. Here's how to choose one that won't slow you down.
- PostgreSQL Row-Level Security: A Practical Guide
Learn how PostgreSQL row-level security (RLS) works, when to use it, and how to write policies that enforce multi-tenant and per-user access at the database layer.