Separate Database Mode
In separate mode each tenant has its own database.
Where to find it
Architect Panel → Configuration:
- Multitenancy — the tenants themselves
- Custom Tenant Information Fields — your own fields on a tenant
- Instance Configuration Fields — settings held per tenant
Architect Panel → Integration & Connections:
- Database Hosts — where tenant databases live
What it gives you
- Isolation at the database level, not the application level. A query cannot accidentally cross tenants.
- Per-tenant backup and restore, so one customer can be restored without touching others.
- Clean deletion — removing a customer means dropping their database.
- Per-tenant placement, which matters for data residency.
- An easy answer to the procurement question.
What it costs
- Every schema change applies everywhere, and can partially fail. With a hundred tenants that is a hundred applications and a hundred things to verify.
- Every backup is a backup per tenant, and testing restores gets proportionally harder.
- Provisioning takes time — a new tenant waits while a database is created.
- Cross-tenant reporting becomes an exercise rather than a query.
- Connection and resource overhead grows with tenant count.
Who needs it
Organisations with a genuine isolation requirement — regulated sectors, government, health, or a small number of large customers who have made it a condition.
Not organisations who simply prefer the idea. The operational cost is real and continuous, and it falls on whoever runs the platform every time anything changes.
Tenant count is the deciding number
Separate mode is comfortable with tens of tenants and painful with thousands. If your model is self-service sign-up, this is almost certainly the wrong mode.
Automate schema changes from the start
Applying a change to every tenant by hand works until it does not, and the failure is a subset of customers on a different schema from the rest. Build the loop and the verification before you need them.
Verify every tenant after every change
Not a sample. Partial application is the characteristic failure of this mode, and the tenants that failed are exactly the ones nobody checked.
Test restores per tenant
The per-tenant restore is a headline benefit of this mode, and it is worth confirming it actually works rather than assuming it follows from the architecture.
Worked example
A platform serving twelve public-sector customers runs separate mode with per-tenant backups, a scripted schema-change loop that reports success per tenant, and an annual restore test on one customer’s database. A change once failed on two tenants; the report caught it the same morning.
Recommendations
- Choose it for a requirement, not a preference.
- Automate schema changes before the first customer.
- Verify every tenant, not a sample.
- Test a per-tenant restore annually.