Multi-Tenancy Architectures: Shared vs Isolated Models

Multi-tenancy is the architectural pattern where a single instance of a software application serves multiple distinct customer organizations (tenants), guaranteeing that no tenant can access or view another tenant's private data.

1. The Pool Model (Shared Compute, Shared Database & Tables)

• All tenants share the same application compute fleet (Kubernetes pods) and the exact same database tables.
• Every table contains a tenant_id partition column (e.g., tenant_id UUID NOT NULL).
• Pros: Lowest infrastructure cost, maximum resource bin-packing density, instant onboarding of new tenants with zero database provisioning delay.
• Cons: High risk of data leaks if an application developer forgets a WHERE tenant_id = ? clause; vulnerability to Noisy Neighbor performance starvation.

2. The Bridge Model (Shared Database Instance, Isolated Schemas)

• Tenants share the database server hardware and connection pool, but each tenant has a dedicated PostgreSQL/MySQL schema (e.g., CREATE SCHEMA tenant_acme).
• Pros: Logical table separation; database user permissions can restrict access at the schema level.
• Cons: Schema migrations become an operational nightmare when managing 5,000+ tenants (running a database migration requires executing 5,000 sequential DDL updates, saturating database metadata locks).

3. The Silo Model (Dedicated Infrastructure per Tenant)

• Each enterprise tenant receives dedicated Kubernetes node pools, isolated VPC networks, and dedicated database clusters.
• Pros: Maximum security isolation, eliminates noisy neighbors, allows custom per-tenant backup/restore schedules, meets strict regulatory compliance (HIPAA, SOC2 Type II, FedRAMP, PCI-DSS).
• Cons: Highest infrastructure cost (sim 10× - 50× higher per tenant); complex operational orchestration.