Per-tenant vs shared infrastructure: the cost curve that decides

Quick answer

Per-tenant infrastructure carries a fixed floor of roughly 150 to 400 dollars a month per tenant for a database, load balancer, and NAT path, regardless of usage. Shared infrastructure spreads that floor across all tenants so marginal cost approaches the actual resource consumption, often under 10 dollars for a small tenant. Dedicated makes sense above the price point where the floor is a small share of revenue, typically enterprise contracts, while everything below that belongs in a shared pool with logical isolation.

The isolation debate usually gets framed as security versus efficiency, which hides the real mechanism. The deciding factor is that dedicated infrastructure has a fixed floor per tenant, and that floor does not shrink when a tenant is small. A tenant using 2 percent of a database still pays for an entire database instance.

Once you write the two cost curves down, the decision usually makes itself, and it is rarely all one or all the other.

The two curves

Model	Fixed cost per tenant	Marginal cost of a small tenant
Dedicated stack	About 150 to 400 dollars a month	Same, regardless of usage
Dedicated database, shared compute	About 30 to 80 dollars a month	Plus actual CPU and memory
Shared everything, logical isolation	Near zero	Actual consumption, often under 10 dollars

The dedicated floor is made of things that cannot be fractionally purchased: a managed database instance at 25 to 60 dollars, a load balancer at 16 to 25 dollars plus capacity, a NAT gateway share at about 33 dollars, backups, and per tenant observability. None of it scales down with a quiet tenant.

Do the arithmetic against price

Compare the floor to the revenue. A 49 dollar per month plan cannot carry a 200 dollar per month dedicated stack, no matter how much simpler it makes operations. A 4,000 dollar per month enterprise contract absorbs it at 5 percent of revenue and buys you a clean isolation story, per tenant restore, and noisy neighbor immunity.

The break point falls where the dedicated floor crosses your acceptable infrastructure share of revenue, commonly 10 to 20 percent for infrastructure heavy products. With a 200 dollar floor and a 15 percent ceiling, that break point is around 1,300 dollars a month of contract value. Below it, share. Above it, dedicate if the customer values it. The related revenue side analysis lives incost per tenant.

Hybrid is the common answer

Most mature platforms end up with tiers rather than a single model. Small tenants share everything with row level or schema level isolation. Mid tier tenants share compute and get a dedicated logical database. Enterprise tenants get a dedicated stack, sometimes in their own account or region for compliance reasons.

The important engineering decision is to make the tier a deployment parameter rather than a code fork. If the same Terraform module and the same application binary serve all three shapes, moving a tenant between tiers is a configuration change. If they diverge into separate code paths, you own three products, and the operational cost dwarfs the infrastructure difference.

The hidden costs on each side

Dedicated infrastructure costs more than the resource bill suggests. Each tenant stack needs upgrades, certificate rotation, patching, monitoring, and a place in the deployment pipeline. Deploying to 200 tenant stacks is a genuinely different problem than deploying to one, and the tooling to do it safely is a real engineering investment.

Shared infrastructure has its own hidden costs. Noisy neighbor control requires per tenant rate limiting and quotas. Per tenant cost visibility requires instrumentation, since the cloud bill has no idea tenants exist. Data isolation needs enforcement at the query layer and proof for auditors. These are cheaper than 200 stacks but they are not free.

Measure before you commit

Before choosing a model, price both from the infrastructure code. If your tenant stack is a Terraform module, c3x can estimate it from the plan with no cloud credentials, which gives you the per tenant floor as a real number rather than a guess. Multiply by expected tenant count and compare against the shared pool estimate.

Do the same for changes. Adding a cache or a second replica to a per tenant module looks like a 30 dollar change in the pull request and is a 6,000 dollar change at 200 tenants. Seeing the per tenant delta next to the tenant count is what keeps that decision honest, and it is the same discipline asmodule level cost estimation anywhere else.

Where the curve bends over time

Both curves move. Dedicated gets cheaper as serverless and scale to zero options mature, since a dedicated database that idles at near zero removes most of the floor. Shared gets cheaper as your pooling improves and utilization rises.

Recompute annually. A model chosen when the floor was 300 dollars may be wrong once serverless databases drop the same shape to 40 dollars for a small tenant, and platforms that never revisit the decision keep paying for an assumption that expired. The curve is the answer, and the curve keeps moving.

FAQ

What does dedicated per-tenant infrastructure cost?

Roughly 150 to 400 dollars per tenant per month as a floor, made of a managed database instance at 25 to 60 dollars, a load balancer at 16 to 25 dollars plus capacity units, a NAT gateway share around 33 dollars, backups, and per tenant observability. None of that scales down when a tenant is quiet, so a tenant using 2 percent of a database still pays for a whole instance.

When should a tenant get dedicated infrastructure?

When the dedicated floor is an acceptable share of that tenant's revenue, commonly 10 to 20 percent for infrastructure heavy products. With a 200 dollar floor and a 15 percent ceiling, the break point is about 1,300 dollars a month of contract value. Below that, share with logical isolation. Above it, dedicate if the customer actually values the isolation.

Is a hybrid tenancy model a good idea?

It is the usual outcome for mature platforms. Small tenants share everything with row or schema level isolation, mid tier tenants share compute with a dedicated logical database, and enterprise tenants get a dedicated stack. The key is making the tier a deployment parameter rather than a code fork, so moving a tenant between tiers is a configuration change rather than three products to maintain.

What are the hidden costs of per-tenant infrastructure?

Deploying, patching, upgrading, rotating certificates, and monitoring 200 separate stacks is a fundamentally different operational problem than doing it once, and the tooling to do it safely is a real engineering investment. Shared infrastructure has its own hidden costs: per tenant rate limiting, quota enforcement, cost instrumentation since the cloud bill does not know tenants exist, and provable data isolation.

How do I price a per-tenant module before committing to it?

Estimate it from the infrastructure code. C3X prices a Terraform plan statically with no cloud credentials, which turns the per tenant floor into a real number you can multiply by expected tenant count and compare against a shared pool. The same check catches changes: adding a replica to a per tenant module looks like 30 dollars in the pull request and is 6,000 dollars at 200 tenants.

What to do next

Price your tenant module before you multiply it by 200. C3X estimates Terraform cost from the plan alone. See the quickstart.