Database Modes
Shared or separate databases — what each means in practice, and what moving between them involves.
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.
Changing Modes
Changing database mode is a migration of every tenant’s data. It is a project, not a setting.
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
Architect Panel → Integration & Connections:
- Deployments — the application versions involved
Why it is hard
The mode determines where every row lives. Moving from shared to separate means extracting each tenant’s rows into a new database and confirming nothing was missed or duplicated. Moving the other way means merging, with the additional problem of colliding identifiers.
Shared to separate is the easier direction
Because you are splitting rather than merging, and each tenant can be verified independently. It is still substantial, and it still needs every tenant checked.
Separate to shared is the harder one
Identifiers that were unique within a database are no longer unique once merged, and every reference between rows has to survive the remapping. This is where a migration goes quietly wrong — a foreign key pointing at the right number in the wrong tenant.
The approach
- Take a full backup and confirm you can restore it.
- Rehearse the whole thing on a copy, end to end.
- Count everything before — rows per table per tenant.
- Migrate one tenant, verify it thoroughly, and use what you learn.
- Migrate the rest in batches, verifying each.
- Count again and compare.
- Have every tenant confirmed before switching the application over.
Count rows, then check meaning
Counts catch missing data. They do not catch data attributed to the wrong tenant, which is the failure that matters most. Check a sample of records in each tenant against what that customer should actually have.
Plan the outage honestly
Data cannot be written while it is being moved. Tell customers the real window rather than an optimistic one, and pick a time that suits them rather than you.
Know when to stop
Define in advance what would make you roll back, and who decides. A migration in trouble at three in the morning is the worst possible moment to be forming that judgement.
Consider whether you need to
Mode changes are usually prompted by a requirement that might have another answer — a customer wanting isolation might be served by moving to a dedicated host under sharding, without changing the mode for everybody.
Worked example
A platform moving from shared to separate rehearsed the whole migration on a restored copy, migrated one willing customer first, then proceeded in batches of five with row counts compared before and after and a sampled records check per tenant. The rehearsal found a table that had been missed entirely.
Recommendations
- Rehearse on a restored copy, completely.
- One tenant first, verified thoroughly.
- Count rows and check meaning — counts alone are not enough.
- Define the rollback trigger and who decides.