Multi-Tenant Architecture

The Question Behind the Question

In every architecture review I've led, there's a moment where someone asks a version of the same question. Sometimes it's framed as "Why does Salesforce have Governor Limits?" Sometimes it's "Why can't we just run longer-running processes?" And occasionally, from the most technically honest stakeholders in the room: "Is this platform actually designed right?"

They're all asking the same thing. They've bumped into the ceiling of a shared infrastructure and they want to understand whether it's a feature or a bug. Whether it's a fundamental architectural trade-off or something Salesforce would do differently if they could.

This tutorial answers that question directly — not with Salesforce marketing language, and not with architectural theorising. With the actual history, the actual trade-offs, and an honest assessment of whether multi-tenancy was the right call then, and whether it remains defensible now.

What Multi-Tenancy Actually Means

The term gets used loosely, so let's be precise. Multi-tenancy means that multiple customers — Salesforce calls them "tenants" — share the same underlying infrastructure: the same application servers, the same database instances, the same runtime environment.

This is fundamentally different from single-tenancy, where each customer gets their own dedicated stack. And it's different from what most public cloud providers offer today, which is closer to elastically partitioned infrastructure — shared hardware but logically isolated execution environments.

How Salesforce Implements Multi-Tenancy

Salesforce's implementation is particularly aggressive. In a standard multi-tenant SaaS product, tenants might share application servers but have separate database instances. Salesforce goes further: all tenants share the same database. Your data sits in the same Oracle database instances as your competitor's data, separated only by an OrgId column in virtually every table.

This is reflected in Salesforce's schema design. The core metadata tables — SystemField, Name, Entity — don't vary by customer. What varies is the data stored in a universal object store called the Entity-Attribute-Value (EAV) pattern, where your custom objects and fields are stored as rows in a generic object table, not as actual database columns.

This is reflected in Salesforce's schema design. The core metadata tables — SystemField, Name, Entity — don't vary by customer. What varies is the data stored in a universal object store called the Entity-Attribute-Value (EAV) pattern, where your custom objects and fields are stored as rows in a generic object table, not as actual database columns.

-- Simplified representation of how Salesforce stores custom object data
-- Your "Opportunity__c" is NOT its own table; it's rows like this:

SELECT *
FROM   sf_object_data
WHERE  org_id     = 'YOUR_ORG_ID'
AND    object_id  = 'Opportunity__c_object_definition_id'
AND    record_id  = 'specific_record_id'

This design has profound implications. It means that adding a custom field doesn't change the database schema. It means that querying across millions of records requires sophisticated indexing strategies. And it means that resource consumption by one tenant can affect the experience of another — which is the root cause of Governor Limits.

Why They Made This Choice in 1999

To evaluate whether Salesforce would make the same decision today, you have to understand what problem they were solving in 1999 — and what the alternatives were.

The Problem: Enterprise Software Was Broken

In 1999, enterprise software meant on-premise installation. Siebel CRM was the market leader. A Siebel implementation required dedicated servers, a DBA team, a consulting engagement, and months of configuration before a sales team could use it. The total cost of ownership was enormous, and the barrier to entry excluded mid-sized companies entirely.

Marc Benioff's insight wasn't just "put CRM on the internet." It was: "Make CRM so cheap and simple to deploy that the economics of enterprise software are fundamentally changed." To do that, you had to eliminate the per-customer infrastructure cost. You had to make the marginal cost of adding a new customer close to zero.

The Infrastructure Constraint: 1999 Cloud Was Not 2024 Cloud

In 1999, "the cloud" didn't exist as we know it. AWS wouldn't launch until 2006. Kubernetes was 15 years away. The options for hosting a web application were: buy your own servers, or rent co-location space. Provisioning a new server for each customer wasn't a software decision — it was a capital expenditure decision that would have made the business unviable.

Multi-tenancy solved this economically. One set of servers. One database cluster. One operations team. Salesforce could price CRM at a per-user monthly fee that companies could afford, because their infrastructure cost was shared across every customer.

The Costs of Multi-Tenancy: What Leaders Rarely See

Multi-tenancy has delivered enormous value. But it comes with real costs that show up in every enterprise Salesforce programme. As a tech leader, you need to understand these — not to avoid Salesforce, but to architect around them intelligently.

Governor Limits: The Shared Infrastructure Tax

Governor Limits are hard caps on how much of Salesforce's shared infrastructure any single transaction can consume. The six main categories are:

• Apex CPU time — 10,000ms per synchronous transaction
• Heap size — 6MB synchronous, 12MB asynchronous
• SOQL queries — 100 queries per transaction
• DML statements — 150 per transaction
• Record rows returned — 50,000 per query
• Future method calls — 50 per transaction

Every enterprise Salesforce programme will hit at least one of these. The standard response from Salesforce partners is "refactor to bulkify" or "move to async." Both are valid — but they're workarounds for a constraint that exists because of multi-tenancy, not because of good API design.

Query Performance: The EAV Penalty

Because Salesforce's custom object data is stored in an EAV structure rather than native relational tables, SOQL query performance behaves differently from what a database architect would expect. Selective queries on indexed fields perform well. Non-selective queries against large data volumes hit timeouts that would be trivial in a dedicated relational database.

This is why Salesforce has an entire advisory programme around Large Data Volumes (LDV). 10 million Account records is not unusual in a large B2B Salesforce org — and managing query performance at that scale requires architectural decisions (skinny tables, custom indexes, archiving strategies) that a dedicated database wouldn't need.

Customisation Ceiling: The Metadata Constraint

Salesforce's metadata-driven architecture — the thing that makes "clicks not code" possible — also creates ceilings. There are limits on the number of custom objects per org, the number of fields per object, the depth of relationship queries. These feel abstract until a programme hits them, at which point they become critical architectural problems with no clean solution.

What Modern Infrastructure Changes

If Salesforce were starting today, they'd have access to infrastructure that simply didn't exist in 1999. The question is whether those tools would lead to a different architectural decision.

Kubernetes and Container Isolation

Kubernetes allows each customer to run in their own isolated container, with resource limits enforced at the infrastructure level rather than the application level. This achieves the same tenant isolation that Governor Limits provide — but without the application-level complexity. A Kubernetes-based multi-tenant architecture would allow each tenant's Apex equivalent to consume resources up to their container's limit, without the 10,000ms CPU ceiling being a global constraint.

Serverless Execution

Serverless platforms (AWS Lambda, Google Cloud Functions) provide per-invocation resource isolation with elastic scaling. Each customer's code runs in its own isolated execution environment. There are still limits — Lambda has a 15-minute execution cap — but they're far more generous than Salesforce's synchronous transaction limits.

Managed Database Services

Amazon Aurora, Google Cloud Spanner, and Azure Cosmos DB offer multi-tenant database architectures with genuine row-level isolation at the database layer, not the application layer. They also support standard SQL rather than a query language (SOQL) designed around the EAV storage pattern.

The Honest Assessment

Would Salesforce choose the same EAV-based, shared-database, application-enforced-limit architecture if they were starting in 2024? Almost certainly not in its current form. The available infrastructure would allow for something that achieves the same economic benefits — low marginal cost per tenant, shared operational overhead — without the same application-level constraints.

What's harder to answer is whether they'd have chosen a different approach entirely. The EAV model gives Salesforce something that container-isolated architectures don't: the ability to do platform-level operations across all tenants simultaneously. A Salesforce release that adds a new feature doesn't require 150,000 database migrations. It requires one metadata update. That is a genuinely powerful capability that modern multi-cloud architectures don't replicate cleanly.

What This Means for Your Architecture Decisions

Understanding multi-tenancy's history and trade-offs changes how you should approach every significant Salesforce architecture decision. Here's the practical translation.

Design for the Limits, Don't Fight Them

Architects who treat Governor Limits as bugs to work around end up building brittle systems. The right approach is to design from the limits outward. If your data volume will exceed 10 million records per object, design the archiving strategy before you build, not after. If your automation logic will exceed CPU limits, design for async from the beginning, not as a refactor.

Multi-Org Is Sometimes the Honest Answer

The Salesforce orthodoxy is "one org." The marketing materials, the partner pitch decks, the Salesforce AE — all will encourage you toward a single org strategy. But when you genuinely need different data residency, different release cadences for different business units, or different governance models, multiple orgs may be the architecturally correct decision. Multi-tenancy within your own enterprise is a legitimate architectural pattern.

Governor Limits Are a Risk Register Item

On any sizeable Salesforce programme, Governor Limit exposure should be a standing item on your risk register. Not because you'll always hit them, but because when you do hit them mid-project, the remediation is expensive. A technical review at the architecture stage — before build — should include an explicit assessment of limit exposure for every integration pattern and automation strategy.

When to Extend Beyond the Platform

For genuinely compute-intensive workloads, Salesforce is not the right place to run the computation. Long-running processes, complex machine learning inference, high-frequency event processing — these belong in external systems, called from Salesforce via platform events or external services, not run within Salesforce's Governor Limit boundaries.

// The wrong way: trying to do heavy computation in Apex
// This will hit CPU limits on large datasets
for (Account acc : [SELECT Id, /* 50 fields */ FROM Account WHERE ...]) {
    // Complex business logic per record
    // Governor limit: 10,000ms CPU - you will hit this
}

// The right way: move compute-heavy work to async/external
// Use Platform Events to trigger external processing
EventBus.publish(new ComputeRequestEvent__e(
    RecordId__c = acc.Id,
    Payload__c  = JSON.serialize(acc)
));

The Verdict

Would Salesforce choose multi-tenancy today? Yes — but not the same implementation.

The economic logic is unchanged. Shared infrastructure enables a pricing model that a per-tenant architecture doesn't. The marginal cost argument that made Salesforce's business model viable in 1999 is just as valid in 2026. What would change is the implementation: container-based isolation over application-enforced limits, native relational storage over EAV for custom objects, infrastructure-layer resource governance over Governor Limits in application code.

But here's what wouldn't change: the fundamental decision to share infrastructure across tenants, and therefore the fundamental constraint that one tenant's consumption must be bounded for the good of others. Governor Limits would still exist in some form. They might be less restrictive. They might operate at the infrastructure layer rather than the application layer. But the underlying constraint — that shared infrastructure requires shared governance — is not a mistake. It's physics.

As a tech leader, the most important thing you can take from this is not a verdict on Salesforce's architecture. It's a mental model. Salesforce is a shared infrastructure platform making specific trade-offs for specific reasons. When you understand those reasons, you make better decisions about when to work with the platform, when to work around it, and when to work outside it.