Salesforce's 2009 SIGMOD paper describes serving many tenants from shared tables with a metadata layer, rather than giving each customer their own schema. Which business-model decision forced that, and what did it cost them?

The situation they were in

The commercial proposition was subscription software that every customer could customise — custom fields, custom objects, custom layouts — while the vendor upgraded everyone at once. Those two promises are in direct tension: per-customer customisation normally implies per-customer schema, and per-customer schema implies per-customer migration on every release, which is the cost structure the subscription model exists to avoid.

What they chose

Shared physical tables with a metadata layer describing each tenant's logical schema. Customer data lives in generic columns; the meaning of those columns for a tenant lives in metadata that the runtime consults. A customer adding a field does not perform DDL, because the field exists as a row of metadata rather than as a column, so what would have been a schema migration across tens of thousands of tenant databases becomes a single insert.

Why it fit their constraints

The capability map explains the decision better than the technology does. Customisation was differentiating; schema management was not. By pushing customisation into data, the parts that differ per tenant became data, and the parts that are the same for everybody became code the vendor upgrades once. That is the general move worth extracting: find the axis along which customers differ, and make that axis data rather than deployment.

What it cost them

• The query optimiser's job gets harder. Generic columns defeat the statistics a database normally relies on, because the optimiser cannot know that column val3 holds dates for one tenant and postcodes for another, which is why the architecture needs substantial supporting machinery: specialised indexing structures, pivot tables and hints derived from the metadata. Without them, queries that should touch 200 rows scan millions and the platform fails under its own success.
• Governor limits become necessary. In a shared runtime, one tenant's expensive operation is every tenant's problem, so the platform must impose hard resource caps on customer code. Those limits are a permanent tax on what customers can build, and they are a direct consequence of the sharing decision.
• The abstraction is load-bearing forever. Everything built afterwards must respect the metadata layer, which constrains what features can exist and how fast they can be added.

When not to copy this

With few tenants, or tenants who do not need to differ from each other, this is a great deal of machinery for nothing. Five enterprise customers with separate databases is simpler, isolates their data by construction, and permits per-tenant tuning and per-tenant compliance regimes that a shared runtime makes hard.

The decision rule: build the metadata layer when the number of tenants makes per-tenant schema migration the constraint on your release cadence. That threshold is usually in the hundreds, not the dozens: 20 tenants means 20 migrations a release, which a team can run in a day, while 2,000 means the migration itself becomes the release process. Below it, separate schemas or separate databases are cheaper, safer and reversible. Above it, the per-release migration cost is what will stop you shipping, and the metadata approach is the answer to that specific problem rather than a general sophistication.

What a strong answer adds

The regulatory dimension that decides many real cases. Shared tables make per-tenant data residency, per-tenant encryption keys and per-tenant retention policies materially harder. A company selling into regulated markets may find that the sharing decision it made for release cadence is the thing blocking a market entry three years later, which is the sort of second-order consequence a capability map is supposed to surface before it happens.