Cost per Tenant and Unit Economics

Which tenants actually make money?

A pooled SaaS gets one infrastructure bill for everyone, but the business needs to know cost per tenant to price plans, set fair limits and spot customers who cost more than they pay. Dedicated (silo) resources are easy: tag them with the tenant and read the bill. Shared resources need allocation: measure each tenant's use of a cost driver, such as CPU seconds, database time, storage bytes or requests, and split the shared cost in proportion. The choice of driver matters: requests may be cheap for one tenant and expensive for another, so pick drivers that track what really costs money. Add fixed per-tenant overheads such as a dedicated database or support. The result is an estimate, not an invoice, but it answers useful questions: is the free tier sustainable, which plan limits are too generous, and which large tenant should move to its own shard and a higher price?

Proportional allocation of a shared bill

Splitting a monthly database bill by measured CPU seconds and comparing it with revenue (amounts in rupees).

shared_db_monthly_cost = 60000      # rupees for the shared database cluster
cpu_seconds = {"acme": 5200, "zen": 600, "kirana": 200}   # measured per tenant
revenue = {"acme": 40000, "zen": 9000, "kirana": 1500}

total = sum(cpu_seconds.values())
for tenant, used in cpu_seconds.items():
    cost = shared_db_monthly_cost * used / total
    margin = revenue[tenant] - cost
    print(f"{tenant:7} cost={cost:8.0f} revenue={revenue[tenant]:6} margin={margin:8.0f}")

Output:

acme    cost=   52000 revenue= 40000 margin=  -12000
zen     cost=    6000 revenue=  9000 margin=    3000
kirana  cost=    2000 revenue=  1500 margin=    -500

Splitting the electricity bill

Flatmates sharing one electricity bill can split it equally, or by who runs the AC all night. Splitting equally feels simple but quietly makes the light users subsidise the heavy one. Proportional allocation is reading a sub-meter for each room.

Act on the numbers carefully

A loss-making tenant is not automatically a bad customer: they may be in a costly onboarding phase or be inefficiently served by a fixable query. Check for performance bugs before repricing, and give notice before changing limits.

Quick check: In the allocation example, acme uses about 87% of the CPU seconds but pays less than its allocated cost. What is the most reasonable first step?

• Delete acme's data to save cost
• Split the bill equally so the problem disappears
• Stop measuring CPU usage
• Investigate acme's heaviest workloads, then consider limits, a different plan or dedicated placement