Isolation Models in Multi-Tenancy
Different applications require different levels of isolation. Let's explore the models from most shared to most isolated.
The Isolation Spectrum
┌─────────────────────────────────────────────────────────────┐
│ SHARED ISOLATED │
│ │
│ Shared Shared Schema Database Dedicated │
│ Schema Database per per Infrastructure │
│ + Partition Tenant Tenant │
│ │
│ ─────────────────────────────────────────────────────────▶│
│ │
│ Lower Cost Higher Cost │
│ Less Isolation More Isolation │
│ Simpler Ops Complex Ops │
└─────────────────────────────────────────────────────────────┘
Model 1: Shared Schema (Pool Model)
All tenants share the same database tables with a tenant identifier:
-- Single table with tenant_id column
CREATE TABLE orders (
id SERIAL PRIMARY KEY,
tenant_id INTEGER NOT NULL, -- Identifies the tenant
customer_name VARCHAR(100),
amount DECIMAL(10,2),
created_at TIMESTAMP
);
-- Query always includes tenant filter
SELECT * FROM orders WHERE tenant_id = 123;
┌─────────────────────────────────────┐
│ Orders Table │
├────────┬───────────┬────────────────┤
│ tenant │ order_id │ amount │
├────────┼───────────┼────────────────┤
│ 1 │ 1001 │ $150.00 │
│ 1 │ 1002 │ $200.00 │
│ 2 │ 1003 │ $75.00 │
│ 3 │ 1004 │ $300.00 │
│ 2 │ 1005 │ $450.00 │
└────────┴───────────┴────────────────┘
Pros:
- Most cost-efficient
- Easiest to maintain
- Simple cross-tenant queries (for admins)
- Fast tenant onboarding
Cons:
- Data leak risk if query misses tenant_id
- Noisy neighbor issues
- Hardest to comply with data regulations
- Difficult to customize per tenant
Best for:
- SaaS with many small tenants
- Non-sensitive data
- Startups optimizing for cost
Model 2: Shared Database, Separate Schemas
Each tenant has their own schema (namespace) in a shared database:
-- Tenant 1's schema
CREATE SCHEMA tenant_1;
CREATE TABLE tenant_1.orders (...);
-- Tenant 2's schema
CREATE SCHEMA tenant_2;
CREATE TABLE tenant_2.orders (...);
┌─────────────────────────────────────────────┐
│ Shared Database │
├─────────────┬─────────────┬─────────────────┤
│ Schema: │ Schema: │ Schema: │
│ tenant_1 │ tenant_2 │ tenant_3 │
│ ┌─────────┐ │ ┌─────────┐ │ ┌─────────┐ │
│ │ orders │ │ │ orders │ │ │ orders │ │
│ │ users │ │ │ users │ │ │ users │ │
│ └─────────┘ │ └─────────┘ │ └─────────┘ │
└─────────────┴─────────────┴─────────────────┘
Pros:
- Better logical separation
- Can customize schema per tenant
- Easier data migration
- Database-level access control
Cons:
- Schema proliferation
- Still shares compute resources
- Connection pool complexity
- Backup/restore per tenant is harder
Best for:
- Medium-sized tenants
- Need for schema customization
- Moderate isolation requirements
Model 3: Separate Database per Tenant
Each tenant has their own database instance:
┌─────────────────────────────────────────────────┐
│ Database Cluster │
├───────────────┬───────────────┬─────────────────┤
│ Database: │ Database: │ Database: │
│ tenant_1_db │ tenant_2_db │ tenant_3_db │
│ │ │ │
│ ┌─────────┐ │ ┌─────────┐ │ ┌─────────┐ │
│ │ orders │ │ │ orders │ │ │ orders │ │
│ │ users │ │ │ users │ │ │ users │ │
│ └─────────┘ │ └─────────┘ │ └─────────┘ │
└───────────────┴───────────────┴─────────────────┘
Pros:
- Strong data isolation
- Can restore individual tenants
- Performance isolation
- Compliance-friendly
Cons:
- Higher infrastructure cost
- Connection management complexity
- Harder to aggregate across tenants
- More operational overhead
Best for:
- Enterprise customers
- Regulated industries
- Tenants with high data sensitivity
Model 4: Dedicated Infrastructure
Complete isolation at the infrastructure level:
┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐
│ Tenant 1 │ │ Tenant 2 │ │ Tenant 3 │
│ Environment │ │ Environment │ │ Environment │
│ │ │ │ │ │
│ ┌───────────┐ │ │ ┌───────────┐ │ │ ┌───────────┐ │
│ │ App │ │ │ │ App │ │ │ │ App │ │
│ │ Server │ │ │ │ Server │ │ │ │ Server │ │
│ └───────────┘ │ │ └───────────┘ │ │ └───────────┘ │
│ ┌───────────┐ │ │ ┌───────────┐ │ │ ┌───────────┐ │
│ │ Database │ │ │ │ Database │ │ │ │ Database │ │
│ │ Server │ │ │ │ Server │ │ │ │ Server │ │
│ └───────────┘ │ │ └───────────┘ │ │ └───────────┘ │
└─────────────────┘ └─────────────────┘ └─────────────────┘
Dedicated Dedicated Dedicated
Servers Servers Servers
Pros:
- Maximum isolation
- Full customization
- Predictable performance
- Simplifies compliance
Cons:
- Most expensive
- Highest operational overhead
- Slowest tenant onboarding
- Resource underutilization
Best for:
- High-security requirements
- Large enterprise customers
- Government/healthcare
- Specific compliance needs
Compute Isolation Models
Shared Processes
All tenants run in the same process:
┌─────────────────────────────────────┐
│ Application Process │
│ ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐ │
│ │ T1 │ │ T2 │ │ T3 │ │ T4 │ │
│ └─────┘ └─────┘ └─────┘ └─────┘ │
└─────────────────────────────────────┘
Container per Tenant
Each tenant gets their own container:
┌───────────┐ ┌───────────┐ ┌───────────┐
│ Container │ │ Container │ │ Container │
│ Tenant 1 │ │ Tenant 2 │ │ Tenant 3 │
└───────────┘ └───────────┘ └───────────┘
│ │ │
└───────────────────────────────────────┘
Container Host
VM per Tenant
Each tenant gets their own virtual machine:
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ VM │ │ VM │ │ VM │
│ Tenant 1 │ │ Tenant 2 │ │ Tenant 3 │
│ ┌───────┐ │ │ ┌───────┐ │ │ ┌───────┐ │
│ │ App │ │ │ │ App │ │ │ │ App │ │
│ └───────┘ │ │ └───────┘ │ │ └───────┘ │
└─────────────┘ └─────────────┘ └─────────────┘
Hypervisor
Network Isolation Models
Shared Network with Tags
┌─────────────────────────────────────────┐
│ Shared Network │
│ ┌─────┐ ┌─────┐ ┌─────┐ │
│ │ T1 │ │ T2 │ │ T3 │ │
│ │Tag:1│ │Tag:2│ │Tag:3│ │
│ └──┬──┘ └──┬──┘ └──┬──┘ │
│ │ │ │ │
│ Security groups / Tags control access │
└─────────────────────────────────────────┘
Virtual Network per Tenant (VPC)
┌───────────────────────────────────────────────┐
│ Physical Network │
│ ┌─────────────┐ ┌─────────────┐ ┌──────────┐ │
│ │ VPC 1 │ │ VPC 2 │ │ VPC 3 │ │
│ │ Tenant 1 │ │ Tenant 2 │ │ Tenant 3 │ │
│ │ 10.0.0.0/16 │ │ 10.1.0.0/16 │ │10.2.0.0 │ │
│ └─────────────┘ └─────────────┘ └──────────┘ │
└───────────────────────────────────────────────┘
Choosing the Right Model
Decision Matrix
| Requirement | Shared Schema | Schema/Tenant | DB/Tenant | Dedicated |
|---|---|---|---|---|
| Lowest cost | ✓✓✓ | ✓✓ | ✓ | ✗ |
| Data isolation | ✗ | ✓ | ✓✓ | ✓✓✓ |
| Performance isolation | ✗ | ✗ | ✓ | ✓✓✓ |
| Customization | ✗ | ✓ | ✓✓ | ✓✓✓ |
| Compliance | ✗ | ✓ | ✓✓ | ✓✓✓ |
| Operational simplicity | ✓✓✓ | ✓✓ | ✓ | ✗ |
Hybrid Approaches
Many platforms offer tiered isolation:
┌─────────────────────────────────────────────┐
│ FREE TIER │
│ Shared schema, shared compute │
├─────────────────────────────────────────────┤
│ PRO TIER │
│ Separate schema, shared database │
├─────────────────────────────────────────────┤
│ ENTERPRISE TIER │
│ Dedicated database, dedicated compute │
└─────────────────────────────────────────────┘
What's Next?
In the next chapter, we'll dive deep into the security considerations of multi-tenancy - how to protect tenant data and prevent unauthorized access.