Sharding Across Hosts
Sharding places tenant databases across several database hosts rather than one.
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 does
Each tenant names the host holding its data. With sharding on, new tenants can be placed on different hosts, so the installation is not limited by one server’s capacity.
When it is worth it
- Capacity — one host cannot hold or serve everything.
- Isolation of load — one heavy tenant should not slow everybody.
- Jurisdiction — some tenants’ data must stay in a particular country.
- A very large customer who has asked for, and pays for, their own infrastructure.
The last two are usually better reasons than the first. Capacity problems are frequently a query or an index rather than a server.
Solve the actual problem
Sharding is a substantial operational commitment. Before taking it on, be confident the constraint is genuinely the database host and not something cheaper to fix — because afterwards you have several hosts with the same problem.
What it complicates
- Backups — several to take, several to test.
- Schema changes — applied everywhere, and partial application is now possible.
- Monitoring — a problem on one host affects some tenants and not others, which is confusing to diagnose.
- Anything crossing tenants — reporting across hosts is a different exercise.
Placement needs a rule
Otherwise tenants land wherever the last one did, and hosts drift into wildly different sizes. Decide how a new tenant is placed — round robin, by region, by size — and write it down.
Record which tenant is where
The tenant record holds it, and you also want it somewhere findable during an incident when the platform is the thing that is down.
Moving a tenant between hosts
Should be a rehearsed procedure, not a first attempt during an emergency. You will need it — for capacity, for a customer request, or for a failing host.
Worked example
A platform shards by region so European customers’ data stays in Europe, with placement decided at onboarding by a written rule. Schema changes are applied host by host with a check after each, and a tenant move has been rehearsed on a test tenant.
Recommendations
- Confirm the constraint is the host before sharding.
- Write down the placement rule.
- Check every host after a schema change.
- Rehearse moving a tenant.