Tenant Placement

A SaaS platform with thousands of small tenants and a handful of enormous ones has two workloads, not one. Any single tenancy model optimises for one distribution and fails the other.

Placement makes it explicit: a routing layer resolves tenant to location, most tenants share tables in a shared database, and the largest get dedicated databases. The real design requirement is not either model — it is the ability to move a tenant between them without a rewrite.

Why it matters

All-shared means the largest customers, who represent most of the revenue, get the least isolation and the least predictable performance. All-dedicated means thousands of databases to patch, back up, migrate and monitor — an operational cost growing linearly with customer count, and the reason small SaaS businesses drown in infrastructure.

Implementation patterns

• Resolve the tenant at the edge, before any data access, and carry the placement through the request context.
• Connection management per placement. A shared pool across placements reintroduces exactly the coupling the split removes.
• The same application code against both, or you have two products and twice the bugs.
• An online migration path: replicate into the new placement via dual-write or CDC, verify, cut over with a brief write pause, and keep a rollback. This should be routine, not a project.
• Per-tenant quotas regardless of placement — queries, connections, storage, background jobs — because placement alone does not stop a noisy neighbour inside the shared tier.
• Attribution by tenant on every resource, so you can identify who caused a spike. Without it the response to a noisy tenant is guesswork.

Industry example

Multi-tenant SaaS platforms such as Freshworks span from single-seat customers to large enterprises whose volume exceeds thousands of small tenants combined. The decisive commercial fact is often not performance but what a dedicated placement makes possible: independent restore, data residency in a specific jurisdiction, a separate maintenance window, and an isolation guarantee that can be written into a contract.

Those are product capabilities delivered by an architectural decision, which is why placement is usually driven by sales requirements as much as by load.

Failure scenarios

• No migration path, so the answer to a tenant outgrowing the shared tier is a bespoke project each time.
• Two code paths for shared and dedicated, diverging over time.
• Quotas omitted in the shared tier, so one aggressive tenant degrades hundreds and the only remedy is a slow migration.
• Placement resolved deep in the stack, after work has already been done against the wrong location.
• Cross-tenant queries written for an internal dashboard that assume shared tables, and break silently for dedicated tenants.

Trade-offs

The hybrid's cost is that you operate two models permanently: two backup regimes, two migration procedures, two monitoring shapes. That is a genuine burden and it is justified only because the alternatives are worse at the extremes of the distribution.

The threshold question is whether your tenant distribution actually has extremes. A platform whose largest tenant is ten times its median does not need this; a platform whose largest is ten thousand times its median cannot avoid it.

Interview question

"Your biggest customer's usage has grown to a third of your shared database's load. Walk me through moving them to a dedicated database with no downtime, and tell me what in your current design would make that hard."