Tenancy

Tenancy#

Tenancy is how the infrastructure separates one customer, team, or mission from another on shared infrastructure. The model runs along a spectrum, a silo gives each tenant its own stack, a pool shares one stack and separates tenants by a key in the data, and the bridge models sit between. Each choice fixes a different blast radius for a single stolen credential or a single bug.

The trade is isolation against density. Silo isolation is the strongest wall and the highest cost per tenant; pooled isolation packs tenants tight and cheap but leans entirely on the application to keep them apart. The tenancy model decides whether one stolen credential reaches one tenant or all of them.

        flowchart LR
  subgraph Silo["Silo, one stack per tenant"]
    SA[Tenant A stack]
    SB[Tenant B stack]
  end
  subgraph Pool["Pool, one shared stack"]
    PS[Shared stack] --> PK{Tenant key in data}
  end

Models#

The model is a single choice with consequences at every layer below it. The operator picks the weakest isolation the threat model and the compliance regime will tolerate, because every step toward silo costs real money per tenant.

Model

Isolation

Cost per tenant

Fits

Silo

Strongest, a full stack per tenant

Highest

Regulated, large, or mutually distrustful tenants

Bridge

Shared platform, isolated store per tenant

Medium

Most B2B SaaS

Pool

Weakest, separated by a key in shared data

Lowest

Many small tenants at high density

Isolation#

Tenancy is enforced layer by layer, not in one place. The further up the stack the wall sits, the stronger and the more expensive it is. The operator decides which layer carries the separation and treats everything below it as shared.

Layer

Isolation primitive

Account

A separate cloud account or project per tenant

Network

A VPC, subnet, or namespace per tenant

Compute

Dedicated instances or per-tenant namespaces

Data

A database, schema, or row-level key per tenant

Identity

A tenant-scoped role or token on every request

Neighbors#

Shared infrastructure means tenants compete for the same CPU, IOPS, and connection pools. Without limits, one tenant’s spike becomes every tenant’s outage, and a malicious tenant can starve the rest on purpose.

  • Quota, a hard per-tenant ceiling on requests, storage, and compute.

  • Throttle, rate limits keyed on the tenant so one caller cannot saturate the pool.

  • Reserve, guaranteed floors for the tenants whose mission cannot wait.

Density#

Density is the whole reason to share infrastructure. Pooling many small tenants onto one stack drives the cost per tenant toward zero, but every shared component becomes a single point of failure and a single point of breach. The operator trades that density back for isolation exactly where a tenant’s data, or the mission’s risk tolerance, demands it. See Cost for the spend side of the same decision.

Pitfalls#

  • App-only separation, one missing tenant filter leaks every tenant at once.

  • Shared credentials, a key reused across tenants collapses the boundary.

  • No per-tenant quota, one tenant starves the rest off shared capacity.

  • Client-supplied tenant id, trusting the request body instead of the token.

  • Silent cross-tenant joins, analytics paths that ignore the tenant key.

References#

Contents