An enterprise platform's application architecture must serve tenants ranging from small businesses to very large enterprises. Should one architecture serve all of them?

Why one shared architecture eventually fails

Shared-table multi-tenancy is efficient and operationally simple, and it makes the largest tenants pay a design cost imposed by the smallest:

• Query plans chosen from aggregate statistics that no individual tenant resembles, so a plan tuned for a thousand rows is applied to fifty million.
• Buffer cache dominated by whoever is busiest, so a large tenant's scans evict everyone else's working set.
• Shared connection and worker pools allocated first-come, so one tenant's burst becomes everyone's incident.
• Blast radius spanning every customer.

No amount of tuning removes these; they are properties of sharing.

Why dedicated per tenant also fails

Operational cost per environment is roughly constant and substantial — provisioning, monitoring, upgrades, certificates, backups. Thousands of dedicated environments means the platform team's work scales with tenant count, which is precisely what a platform exists to prevent. Migrations become an estate-wide programme with partial-failure states.

The tiered architecture

Shared with enforced quotas for the many. Per-tenant limits on connections, concurrent jobs, query cost and storage, with fair scheduling rather than first-come for background work. Quotas visible to the customer, because a limit they cannot see is an outage they hit by accident.

Dedicated cells for the few. Full stacks serving a small number of large tenants, capping blast radius structurally rather than by policy — and giving commercial optionality, since dedicated capacity is something enterprises will pay for.

An explicit, measured promotion path. A threshold — data volume, query cost, request rate — that triggers migration, with the migration tooling built and rehearsed. Discovering the need for a dedicated tier during an incident, with nothing prepared, is the common and avoidable outcome.

What must be true regardless of tier

• Tenant as the leading column in every index, so selectivity is evaluated within a tenant.
• Per-tenant observability, with alerting on outliers rather than on aggregates — an aggregate is dominated by the many small tenants and blind to the few large ones being completely broken.
• One codebase across tiers. Different infrastructure, same application, or the platform becomes two products.