Salesforce's Metadata-Driven Multi-Tenancy
Salesforce serves every customer from shared infrastructure with a single physical schema, storing customer-specific data structures as metadata rather than as separate tables.
The problem
A SaaS platform where every customer can define custom objects, custom fields, custom validation and custom workflow. The obvious implementations both fail at scale:
- A database per customer means tens of thousands of schemas to migrate, back up, monitor and upgrade. Operationally impossible at that count, and it destroys the economics.
- A table per customer object produces an unbounded number of tables and the same problem.
The approach
Salesforce's published architecture uses a metadata-driven model. Customer data is stored in a small number of generic physical tables with wide, polymorphic columns; the meaning of each column for each tenant is held in a metadata layer. A runtime engine reads the metadata and constructs the appropriate query.
Additional structures — pivot tables for indexing, and materialised structures for relationships — recover the performance that a purely generic layout would lose.
Why it is a strong design
Customisation without DDL. A customer adding a field is a metadata insert, not a schema migration. That is what makes tenant-level customisation possible at all at that scale.
One physical schema to operate. Upgrades, backups, monitoring and tuning happen once, not once per tenant, which is the whole economic argument for multi-tenancy.
Tenant isolation enforced in one place — the query construction layer — rather than trusted to every query an engineer writes.
The costs, honestly
The engine is complex and the query patterns are unusual, so ordinary database tuning intuition does not apply. Very large tenants strain shared resources and need governor limits — the API and execution limits Salesforce is known for are a direct consequence of shared infrastructure, and they are the visible price customers pay for the model.
The transferable decision
Multi-tenancy sits on a spectrum: silo (dedicated infrastructure per tenant — strong isolation, poor economics), bridge (shared infrastructure, separate schemas or databases), and pool (fully shared, tenant ID on every row — best economics, isolation enforced in software).
Most SaaS platforms should start pooled and move specific large or regulated tenants to bridge or silo as required. The mistake is choosing silo early for perceived safety and discovering at a thousand tenants that the operational cost has become the business model's ceiling.