In Separate Database Mode, each tenant gets its own physical database. The application chooses which database to connect to based on the current tenant. This is the multi-tenant pattern most appropriate for high-security or regulated industries.
How It Works
The platform maintains a small directory database (tenant lookups, billing, sign-in) plus one application database per tenant. On every request, after authentication the platform switches to the appropriate tenant DB and serves the rest of the request from there.
Pros
- Strong isolation: A bug or misconfiguration cannot leak data between tenants. The DB connection is fundamentally different.
- Per-tenant backups are trivial — back up the tenant's DB.
- Per-tenant restore is a simple drop-and-load — no row-level surgery.
- Customisation: If a tenant needs a custom column, you can add it to just their schema.
- Compliance: Often required by HIPAA, banking, government contracts.
Cons
- Higher infrastructure cost — many DB instances or schemas.
- Schema migration overhead — every migration runs N times, increasing the window for incidents.
- Cross-tenant analytics are harder — requires a separate data warehouse / ETL.
- Connection-pool tuning matters more — too many tenants exhaust DB connections.
Worked Examples
- Healthcare SaaS: Each hospital is a separate DB so a HIPAA audit can prove physical separation.
- Government tenants: Each agency requires a dedicated DB with its own backup chain.
- Enterprise on-prem: Customer chooses to host their own DB; the application connects to it remotely.
- High-revenue tenants: A “premium tier” gets a separate DB for performance isolation; lower-tier tenants share a DB.
Note: Hybrid deployments are supported — some tenants on shared, some on separate. The mode is per-tenant, so you can graduate a tenant from shared to separate without affecting the rest.