Multi-Tenancy Architecture Decisions
Building a multi-tenant SaaS platform requires making critical architecture decisions early that are expensive to change later. The three fundamental decisions are database strategy, authentication model, and tenant isolation level.
Database Strategies
Shared Database, Shared Schema — All tenants share tables with a tenant_id column. Lowest cost, simplest operations, but requires careful query discipline and makes tenant data migration harder.
Shared Database, Separate Schemas — Each tenant gets their own database schema. Good balance of isolation and cost. Schema migrations must be applied across all tenant schemas.
Separate Databases — Complete data isolation. Highest cost but simplest compliance story. Essential for healthcare or financial services tenants with strict data residency requirements.
Authentication & Tenant Resolution
Tenant resolution determines which tenant a request belongs to. Common approaches:
- Subdomain-based: tenant1.app.com, tenant2.app.com
- Path-based: app.com/tenant1, app.com/tenant2
- Header-based: Custom header or JWT claim
Data Isolation Enforcement
Row-Level Security (RLS) — PostgreSQL's RLS policies automatically filter queries by tenant. This is the gold standard for shared-schema architectures because it prevents data leaks even if application code has bugs.
Application-Level Filtering — Middleware injects tenant context into every database query. Simpler to implement but relies entirely on application code correctness.
Scaling Patterns
As your SaaS grows, plan for:
- Noisy neighbor mitigation — Rate limiting and resource quotas per tenant
- Tenant-specific scaling — Large enterprise tenants may need dedicated resources
- Data partitioning — Shard by tenant for horizontal database scaling
Conclusion
Start with shared database and shared schema for speed to market. Add schema isolation or separate databases for enterprise customers who require it. Design your data access layer to support migration between strategies.
Tags