Multi-tenant architecture is a software design where a single instance of an application and its supporting infrastructure serve many customers (tenants) simultaneously, with each tenant’s data and customizations isolated from the others. It’s the foundational architectural choice that lets Salesforce run thousands of customers — from one-user trial orgs to Fortune 50 enterprises — on the same shared platform without them seeing each other’s data.
The single-tenant alternative
Imagine the opposite — single-tenant — to see why multi-tenant matters:
- Single-tenant: each customer gets their own dedicated server, OS, database, application instance. Upgrades happen per customer. Each customer pays for under-utilized capacity. Vendor maintenance scales linearly with customer count.
- Multi-tenant: all customers share one platform. Upgrades happen once, for everyone, atomically. Capacity is pooled. Vendor maintenance is constant regardless of customer count.
Multi-tenancy is what makes the SaaS economics work.
How Salesforce implements it
Salesforce’s multi-tenant model has a few notable properties:
- Shared database, partitioned by Org ID. All tenants’ records live in the same physical tables, with an
OrgIdcolumn on every row. Every query is automatically scoped to the running user’s org. - Metadata-driven customization. Tenants customize through metadata — fields, objects, layouts, flows, code — not by modifying the platform’s core code. The platform reads metadata at runtime to render each tenant’s customized experience.
- Strict tenant isolation. A query in one org cannot return rows from another. Sharing rules, profiles, and FLS apply only within the tenant. APIs are scoped to the authenticating tenant.
- Shared upgrades. Three times a year (Spring, Summer, Winter), Salesforce upgrades the entire platform — every customer at once. Custom code and metadata are preserved through the upgrade because they’re isolated from the core platform.
- Resource governance. Governor limits exist precisely because it’s multi-tenant — no single tenant can monopolize CPU, memory, or database I/O to the detriment of others.
Trade-offs
The benefits are large but real trade-offs exist:
- Governor limits. You can’t write Apex that runs for an hour or queries millions of records without batching — governor limits keep one tenant from starving others.
- No direct DB access. You can’t issue arbitrary SQL or attach an external tool to the underlying database — you work through Salesforce’s APIs.
- Shared release schedule. You don’t choose when you get upgraded; Salesforce decides. Enterprise customers can defer to “preview” sandboxes ahead of production, but they can’t refuse a release.
These trade-offs are also why interviewers ask about multi-tenancy — they want to know you understand why Salesforce works the way it does (governor limits, metadata model, release schedule) rather than fighting it.
Quick interview answer
“Multi-tenant architecture means one shared application instance and infrastructure serves many customers, with strict isolation between tenants’ data and customizations. Salesforce uses a metadata-driven multi-tenant model — all orgs share the database (partitioned by OrgId) and customize through metadata, not forked code. This is why Salesforce can release three upgrades a year without breaking customer customizations, and why governor limits exist.”
Verified against: Trailhead — Salesforce Platform Basics and Salesforce architecture whitepapers. Last reviewed 2026-05-17.