What is Multi-tenancy?
When building SaaS, you need to decide database architecture: separate database per customer (multi-database) or shared database with tenant_id (shared database)?
Option 1: Shared Database + Row-level Isolation
All customers share one database, isolated by tenant_id column in every table.
Pros
- Easy to manage: Just one database, one connection pool
- Cost-effective: Good for startups with many small customers
- Simple backup: One backup for all
Cons
- Noisy neighbor: One tenant's heavy query can affect entire system
- Hard to scale: Can't scale separately for large tenants
- Compliance: Some customers require physical data isolation
Option 2: Schema-per-Tenant
Each tenant gets a separate PostgreSQL schema within the same database.
Pros
- Better isolation: Each tenant has separate schema
- Easier migration: Can migrate tenants individually
- Performance: Indexes not bloated by other tenant data
Option 3: Database-per-Tenant
Each tenant gets completely separate database.
Pros
- Maximum isolation: Each tenant completely independent
- Flexible scaling: Large tenants can use bigger RDS instance
- Compliance: Meets strict security regulations
Cons
- High cost: Each database needs 1 RDS instance
- Complex management: Must monitor many databases
- Migration hell: Migrating 100 tenants = running migration 100 times
Recommendations by Stage
| Stage | Tenant Count | Architecture |
|---|---|---|
| MVP / Startup | < 100 | Shared DB + RLS |
| Growth | 100 - 1,000 | Schema-per-tenant |
| Enterprise | > 1,000 or whale customers | Hybrid: Shared for small, DB-per-tenant for large |
Conclusion
No solution is perfect for all cases. Choose architecture based on:
- Start small: Shared database with RLS
- Prepare for migration: Design code from start to allow future transitions
- Monitor early: Track query performance per tenant to know when to switch
TechCorp has helped 15+ SaaS customers design optimal multi-tenant architecture. Contact us for free consultation!
EngineeringCloud
Share