The Question
A multi tenant application serves many customers, called tenants, from shared infrastructure. The data model must decide how strongly to isolate one tenant from another, trading isolation and security against cost and operational simplicity.
Three Common Models
- Shared table: all tenants share tables, with a tenant id column on every row. Cheapest and densest, but a missing tenant id filter can leak data across tenants.
- Schema per tenant: each tenant gets its own schema within one database. Stronger isolation and easy per tenant backups, but thousands of schemas strain the catalog.
- Database per tenant: each tenant has a dedicated database. Strongest isolation and noisy neighbor protection, but the most overhead to provision and operate.
Choosing
- Many small tenants favor the shared table model for density.
- A few large or regulated tenants favor database per tenant for isolation.
- Schema per tenant sits in between.
Cross Cutting Concerns
- Enforce the tenant filter centrally, ideally with row level security, so a forgotten filter cannot leak data.
- Plan for tenant migration between models as tenants grow.
Key idea
Multi tenancy spans shared table, schema per tenant, and database per tenant models, trading density and cost against isolation strength.