Multitenancy
Multitenancy is the architecture that runs many customer organizations (tenants) on the same shared infrastructure.
Definition
Multitenancy is the architecture that runs many customer organizations (tenants) on the same shared infrastructure. The same servers, the same database, and the same application code serve every tenant at once. Each tenant's data stays logically isolated from every other tenant, while the underlying compute and storage are pooled. Salesforce describes its platform as multitenant and metadata-driven, and it has been built this way since the company's founding in 1999.
A single Salesforce instance uses one shared multitenant database with a single schema. A multitenant kernel reads metadata and data at runtime to serve each tenant a customized application. Multitenancy is the reason Salesforce can ship the same release to thousands of customers on one schedule. It also explains governor limits, the metadata-driven customization model, and why every customer runs an identical code base.
How one platform serves thousands of tenants at once
Shared infrastructure with logically isolated data
Multitenancy pools physical resources across many customer orgs. The same servers and the same database tables hold data for thousands of tenants at the same time. Isolation is logical, not physical. Salesforce partitions all platform data, metadata, and pivot tables by OrgID using native database partitioning. Every row carries the org it belongs to, so a query for one tenant never returns another tenant's records. This is the opposite of single-tenant software, where each customer gets a dedicated database and a dedicated copy of the application. In that older model, the vendor maintains and upgrades each instance separately. Salesforce instead maintains one logical application and lets partitioning keep tenants apart. The shared schema is fixed and standard, so customers do not alter the underlying tables. They add custom objects and fields as metadata that the platform represents inside its own dictionary. The data still lands in the same shared structures behind the scenes. Understanding this separation between the physical schema and the logical, per-tenant view is the foundation for everything else about how the platform behaves.
The metadata-driven runtime
Salesforce pairs multitenancy with a metadata-driven design, and the two depend on each other. Because every tenant shares the same code, per-tenant behavior cannot live in the code itself. It lives in metadata instead. The platform keeps a Universal Data Dictionary that stores each tenant's objects, fields, layouts, validation rules, and other definitions. A multitenant kernel, the application runtime, reads that metadata and data at runtime. It then assembles the right application, business logic, and APIs for whichever tenant is making the request. When an admin creates a custom field, no new database column appears for that tenant alone. The platform records the field as metadata and maps it into shared storage. When a user loads a page, the runtime reads the metadata and renders the layout that tenant configured. This indirection is what lets one running system look completely different to two different customers. It also means customization is fast and safe. Adding a field is a metadata change, not a schema migration, so it takes effect without downtime for anyone else on the same infrastructure.
Governor limits as a tenant-protection mechanism
Governor limits exist because the platform is multitenant. Salesforce states that because Apex runs in a multitenant environment, the Apex runtime engine strictly enforces limits so that runaway code or processes do not monopolize shared resources. One tenant's poorly written trigger could otherwise consume the CPU, memory, and database capacity that every other tenant on the same instance relies on. The limits draw a hard boundary around each transaction. Examples include a cap of 100 SOQL queries and 150 DML statements per synchronous transaction, plus ceilings on CPU time and heap size. When code crosses a limit, the runtime throws an exception that the code cannot catch and continue past. These limits are not punishment. They are the contract that makes resource sharing fair and predictable. They cannot be lifted for a single org, because lifting them would let one customer degrade the experience for neighbors sharing the same servers. Designing inside the limits is therefore a core skill, not an edge case, for anyone building on the platform.
Customization without code branches
In a single-tenant world, a vendor can fork the code for one demanding customer. Multitenancy removes that option. Every tenant runs the same application, so there is no per-customer branch to maintain. Customers shape the platform through configuration rather than through private copies of the source. Custom objects, fields, page layouts, flows, validation rules, and permission sets are all metadata. Even Apex and Lightning components are packaged and namespaced so they coexist safely with everyone else's code on the shared runtime. This constraint is a feature. It keeps every org on a clean, upgradable foundation and prevents the slow drift that plagues forked, customized software. It also shapes how teams approach a project. The first question is usually whether configuration can solve the need before any code is written. When code is required, it has to bulkify and respect governor limits, because it runs on the same shared engine as every other tenant. The discipline that multitenancy imposes is the reason orgs stay maintainable as they grow over many years.
Coordinated releases for everyone at once
Multitenancy makes Salesforce's release model possible. The company ships three major releases each year: Spring, Summer, and Winter. Because every org runs the same code base, those releases roll out to all tenants on a shared schedule rather than as separate per-customer upgrades. There is no migration project for each org and no version sprawl across the customer base. The upgrade happens at the platform level and reaches everyone in waves over release weekends. Customers do not opt out of the platform version, though they can preview upcoming changes in a sandbox before the production rollout. That preview window matters. Since a new release reaches every tenant, teams test their customizations against it ahead of time to catch anything that behaves differently. The trade-off is clear and intentional. Customers give up control over exactly when they upgrade. In return they always run a current, patched, uniformly supported platform with no legacy versions to nurse. That uniformity is only achievable because the architecture is multitenant from the database up.
Hyperforce and modern multitenancy
Hyperforce is Salesforce's next-generation infrastructure, built for the public cloud. It is composed of code rather than hardware, which lets Salesforce deliver the platform to new regions quickly and give customers more control over data residency. Hyperforce runs on public cloud providers and is available in more than 20 regions worldwide. The multitenant and metadata-driven principles do not change with Hyperforce. The same shared database, single schema, OrgID partitioning, and metadata kernel still define how tenants are served. What changed is the layer underneath. Instead of Salesforce-operated data centers, the platform now runs on provider infrastructure described entirely in code. Each Hyperforce instance maps to an availability region and spreads its critical services and data across at least three availability zones for resilience. Existing orgs migrate from legacy infrastructure to Hyperforce regions over a multi-year schedule. For most admins and developers the move is invisible, because the tenant abstraction is identical. Hyperforce shows that multitenancy is an architectural pattern, not a specific set of machines, and that the pattern travels cleanly onto public cloud.
How multitenancy shapes day-to-day design
Almost every Salesforce best practice traces back to multitenancy. Bulkification exists because governor limits cap how much work one transaction can do, and limits exist to protect shared resources. The preference for configuration over code exists because there are no per-tenant code branches. Selective query design and proper indexing matter because queries run against partitioned tables shared with thousands of other orgs. Consider a worked example. A developer writes a trigger that issues one SOQL query for each record in a batch. With 200 records that becomes 200 queries, well past the 100-query limit, and the transaction fails. Rewriting it to query once for all 200 records keeps it inside the limit and runs efficiently for every tenant. The single-tenant instinct of looping freely over data simply does not survive here. Engineers coming from dedicated-server backgrounds often need to unlearn that habit. Once the constraints click, they stop feeling like obstacles. They become a predictable rulebook that keeps a shared platform fast, fair, and stable for everyone who depends on it.
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on Multitenancy.
Hands-on resources to go deeper on Multitenancy.
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…