Multitenancy
Multitenancy is the architectural pattern that runs many customer organizations (tenants) on the same shared physical infrastructure: the same servers, the same database, the same application code.
Definition
Multitenancy is the architectural pattern that runs many customer organizations (tenants) on the same shared physical infrastructure: the same servers, the same database, the same application code. Each tenant''s data is logically separated from every other tenant''s data, but the underlying compute and storage are shared. Salesforce was built as a multitenant platform from its founding in 1999; the entire Salesforce stack (Sales Cloud, Service Cloud, Marketing Cloud, Heroku, MuleSoft) shares this architectural foundation.
Multitenancy is the reason Salesforce can ship the same release to thousands of customers simultaneously, deliver dramatic cost efficiencies versus single-tenant alternatives, and enforce governor limits to protect tenant-to-tenant resource sharing. The pattern also constrains how customers can customize: every customer runs the same code base, so customization happens through metadata configuration rather than per-tenant code branches. The metadata-driven philosophy and the governor-limits enforcement both derive directly from the multitenant architecture.
How Multitenancy shapes the Salesforce platform
Shared infrastructure, isolated data
Multitenancy runs many customer orgs on shared servers and a shared database. Each org''s data is isolated logically (via per-org ID columns on every row) but stored in the same physical tables. The same application code runs the same logic for every tenant; per-tenant behavior comes from metadata that the code reads at runtime.
Cost efficiency
The shared-infrastructure model produces dramatic cost efficiencies versus single-tenant alternatives. One server can host thousands of small customer orgs; the per-customer cost is a fraction of running one server per customer. Salesforce passes these efficiencies through to customers via subscription pricing that''s often a tenth of equivalent single-tenant offerings.
Governor limits as a tenant-protection mechanism
Multitenancy requires governor limits. If one customer''s code could consume unlimited CPU, RAM, or database I/O, that one customer would degrade every other tenant on the same infrastructure. Governor limits enforce per-transaction caps that guarantee no single tenant can monopolize shared resources. The 100 SOQL queries, 150 DML statements, 10-second CPU limits all derive from this architectural necessity.
Metadata-driven customization
Customers cannot deploy per-tenant code branches in multitenancy. The same code runs for everyone; per-tenant behavior comes from metadata configuration (custom objects, fields, validation rules, flows, Apex packaged with namespaces). The metadata-driven approach is the architectural enabler of customer customization in a multitenant world.
Coordinated releases
Multitenancy makes coordinated releases possible. Salesforce ships three Major Releases per year to thousands of customer orgs simultaneously because every org runs the same code base. The release rolls out to all tenants in waves over a few weekends; there''s no per-customer upgrade work because there''s no per-customer code branch to upgrade.
Hyperforce and modern multitenancy
Hyperforce, Salesforce''s 2021 infrastructure refresh, runs the multitenant platform on public cloud (AWS, GCP, Azure) regions rather than Salesforce-managed pods. The multitenant principles remain the same; the underlying compute layer changed. Customer orgs migrate from legacy pods to Hyperforce regions on a multi-year schedule.
Limits and design trade-offs
Multitenancy''s constraints shape every Salesforce design pattern. Governor limits force bulkification; metadata-driven customization rules out per-tenant code; shared schemas mean every table has an OrgId column. Developers and admins design within these constraints; engineers building on other platforms often need to unlearn assumptions from single-tenant world.
Work effectively within the Multitenant platform
Multitenancy is platform-level architecture, not a feature to configure. The work is designing solutions that respect the constraints.
- Bulkify all code
Apex code must handle 200 records as efficiently as one. SOQL inside loops, DML inside loops, both fail bulk scenarios. Use Map-based patterns.
- Respect governor limits
100 SOQL queries, 150 DML statements, 10s CPU, 6MB heap per synchronous transaction. Design within these caps; reach for async (Queueable, Batchable) when needed.
- Use metadata, not code, for customization
Custom fields, flows, validation rules are the primary customization tools. Reserve Apex for cases where declarative tools genuinely fall short.
- Design for selectivity
SOQL queries must be selective (filter on indexed fields). High-volume scans hit the selectivity threshold and fail.
- Plan for shared release schedules
Salesforce releases are platform-wide. Test in sandbox before each major release; surprises in production are not the customer''s fault but are the customer''s problem.
- Architect with the constraints in mind
Multitenancy is non-negotiable. Every architectural decision must respect it; trying to bypass produces fragile solutions.
- Multitenancy constraints feel restrictive compared to single-tenant platforms. They''re non-negotiable; design within them rather than fighting them.
- Governor limits cannot be increased per-org. Salesforce Support cannot raise them; redesign is the only path.
- Per-tenant code branches do not exist. Customization happens through metadata configuration; trying to clone per-customer is anti-architectural.
- Performance varies by org due to shared infrastructure. A neighboring tenant''s heavy work can produce transient slowness; not always under your control.
Trust & references
Cross-checked against the following references.
- Execution Governors and LimitsSalesforce Developers
Straight from the source - Salesforce's reference material on Multitenancy.
- HyperforceSalesforce Help
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What is Multitenancy?
Q2. Why do governor limits exist?
Q3. How does Salesforce handle customer customizations?
Discussion
Loading discussion…