Multi Tenant Schema Design
A multi tenant application serves many customers, called tenants, from shared infrastructure. The central question is how strongly to isolate each tenant data. There are three classic models along an isolation versus efficiency spectrum.
- Shared table all tenants share the same tables, and every row carries a tenant id column. Every query must filter by tenant id. This is the cheapest to operate and easiest to scale to many small tenants, but a single missing tenant filter can leak one tenant data to another, so the model leans hard on application discipline or row level security.
- Shared database separate schema each tenant gets its own schema of tables inside one database. Isolation is stronger and per tenant customization is easier, but thousands of schemas strain tooling and migrations must run per schema.
- Separate database each tenant gets a dedicated database. Isolation is strongest and noisy neighbors are contained, but operational cost and connection overhead grow with tenant count.
A frequent default is the shared table model with a mandatory tenant id on every table and row level security enforcing the filter in the database itself, so a forgotten where clause cannot leak data. Large or regulated tenants can be promoted to their own schema or database. The right choice balances tenant count, isolation requirements, and the cost of running migrations across many copies.
Key idea
Multi tenant schemas trade isolation against efficiency across shared table, separate schema, and separate database, with a tenant id plus row level security being a common safe default.