Salesforce's multi-tenant design - described in its 2009 SIGMOD paper - stores customer-specific structures as metadata over shared tables rather than giving each tenant its own schema. What does that platform-wide constraint buy the vendor and what does it charge its customers?

What is gained

One physical schema for every tenant means one upgrade for every tenant. That is the entire proposition, and it is worth stating in the currency the business uses: a vendor with per-tenant schemas runs a migration programme per release; a vendor with a metadata-driven schema runs a deployment.

Concretely, the shared design buys:

• Upgrade cost that is constant rather than proportional to customer count. The difference compounds: at 1,000 tenants a per-tenant migration is a programme; at 100,000 it is impossible.
• Customisation without DDL. Tenants add fields and objects by writing metadata rows, so a customer change is a data change - no schema lock, no per-tenant deployment, no risk to neighbours.
• Uniform operations. One backup strategy, one index strategy, one performance profile to reason about.
• Release cadence independent of customer count. A release reaches 100% of tenants on the vendor's own schedule, because there is nothing per-tenant to migrate or negotiate.

What is paid, and by whom

The vendor pays in engine complexity. A generic storage layout needs a query layer that reconstructs typed, indexed, tenant-scoped access over untyped shared storage, including its own pivot and index structures. That is a serious, permanent engineering investment, and it is the reason this design is rare outside companies whose product is the platform.

The customer pays in limits. Governor limits, field counts, query shapes that are not expressible, and performance characteristics that cannot be tuned per tenant are all consequences of the shared layout. The customer's flexibility is bounded by what the metadata model can express, and that boundary is not negotiable per account.

There is a third payer: the noisy-neighbour risk is structural. Shared tables mean shared resources, so isolation has to be re-created in software through quotas and throttles rather than obtained for free from separate databases.

When the bill arrives

At the point a large customer needs something the metadata model cannot express. Early tenants never notice the constraint; the largest ones hit it, and they are the ones with the negotiating power. The vendor's answer has to be a platform capability rather than a bespoke accommodation, which means the roadmap is partly set by whichever large customer hit the wall first.

The general principle

This is a platform-wide constraint chosen deliberately to make one operation cheap. The pattern generalises well beyond multi-tenancy: accept a restriction on what anyone can express, and buy a property that scales with the number of participants. A single wire format, one deployment topology, one language runtime on the paved road - all the same trade.

Judge them all the same way: choose the constraint when the operation it cheapens happens often enough for its cost to dominate, and reject it when the restriction lands on the 20% of customers who generate most of the revenue.

When this is the wrong answer

• Few, large, highly differentiated tenants. With twenty enterprise customers each wanting genuine schema-level difference, per-tenant databases are simpler, isolation is free, and the migration cost is affordable.
• Strict data-residency or per-tenant encryption requirements, where shared tables create a compliance argument you will keep having.
• When you cannot fund the engine. The design only pays if you build the query and metadata layer well; a half-built version gives you the constraints without the benefits, which is the worst of both. The characteristic failure is a shared-table layout with no metadata-aware query planner: every tenant's query degrades as the largest tenant grows, and there is no per-tenant index to add.