Fully-Loaded Tenant Cost

The intuitive model of a multi-tenant service is that cost scales with usage, so a tenant with almost no data and almost no traffic costs almost nothing. For a managed service this is substantially false, because a large share of the cost is per-tenant rather than per-request.

Fully-loaded tenant cost accounts for the terms that do not scale down:

infrastructure floor + amortised control-plane cost + backup floor + (support volume × cost per interaction) + (fleet engineering effort ÷ tenant count) + abuse handling + abandoned-resource retention.

Why it matters

Pricing and free-tier decisions are made against a cost model, and a model that assumes proportionality produces a business that loses money on most of its customers without knowing it. The characteristic finding, once the loaded cost is computed, is a large population of tenants whose cost exceeds their revenue by a wide margin, cross-subsidised by a small number of large accounts.

That structure is entirely viable — it is the standard freemium model — but only if the conversion rate justifies it, and the conversion rate is a number that must be measured rather than assumed. A free tier is a marketing expense and should be evaluated as cost per acquired paying customer, compared against other acquisition channels.

Implementation patterns

• Compute the loaded cost per tenant and segment by tenant size, then plot cost against revenue. The shape of that plot is the whole analysis.
• Attribute support and abuse handling, which are frequently the terms that break the arithmetic and are almost never in an infrastructure cost model.
• Amortise fleet engineering by tenant count, since a version upgrade or migration costs roughly the same per instance regardless of that instance's size.
• Shared clusters with logical isolation to collapse the per-tenant infrastructure floor — usually the largest single term — accepting a noisy-neighbour problem that quotas must manage.
• Scale to zero with separated storage, so an idle tenant pays for bytes and nothing else. This is the architectural change that makes small tenants viable, and it is the reason serverless database products exist.
• Automated cleanup of abandoned resources, since the retained-forever tail is pure loss and is usually material.
• Hard, enforced quotas on lower tiers, bounding the worst case per tenant.
• Self-service-only support below a revenue threshold.

Industry example

PlanetScale's 2024 decision to discontinue its free tier is the clearest recent instance: the stated reasoning was that supporting free databases consumed engineering and infrastructure resources out of proportion to their value. The underlying arithmetic is the general one — per-tenant floors, fleet operations that scale with instance count, and support burden that does not fall with tenant size.

The counter-examples are equally instructive. Products that sustain very large free populations — serverless database offerings with genuine scale-to-zero and separated storage — have changed the architecture so the floor is near zero, rather than accepting the floor and subsidising it.

Failure scenarios

• Pricing set from marginal infrastructure cost, ignoring every per-tenant floor.
• Support cost excluded from the model, which is frequently the largest omitted term.
• Fleet engineering effort treated as fixed overhead, hiding that it scales with instance count.
• Abandoned tenants retained indefinitely, accumulating storage, backups and control-plane work forever.
• A free tier with advisory rather than enforced limits, so the worst case per tenant is unbounded.
• Conversion rate never measured, leaving the tier's justification untested.
• An instance-per-tenant architecture at a tenant count where the floor dominates, with no path to shared clusters.

Trade-offs

Reducing per-tenant cost means shared infrastructure and weaker isolation. A shared cluster with logical separation is dramatically cheaper and gives up the blast-radius and performance-isolation properties of dedicated instances — which some customers require contractually, and which becomes a tiering decision rather than an architectural one.

Scale-to-zero trades cold-start latency for idle cost, which is unacceptable for latency-sensitive workloads and entirely fine for the small tenants it is designed to serve. Applying it uniformly harms the customers who pay the most.

The trade is isolation and predictable latency in exchange for a per-tenant cost floor low enough to serve small customers profitably. The resolution is almost always tiering: shared and scale-to-zero at the bottom, dedicated and always-warm at the top, with the architecture supporting both rather than picking one.

Interview question

"We have 80,000 free accounts and 900 paying ones. Tell me how you would work out what the free accounts actually cost us, what you would expect the largest term to be, and what you would change architecturally before recommending we cancel the tier."