Multi-Tenancy

Multi-tenancy is a cloud software architecture model in which a single instance of the system, running on shared infrastructure, serves many customers at once. Each customer is called a tenant, and even though they all use the same code and the same database, each tenant's data stays logically isolated: no one sees anyone else's information. It is the pattern that makes the SaaS (software as a service) model possible as we know it.

The classic analogy is an apartment building: all the tenants share the structure, the plumbing and the elevator (the infrastructure), but each one has their own apartment with a key (their private data). The opposite is the single-tenant model, where each customer gets their own dedicated instance, like a single-family house.

Salesforce was one of the pioneering platforms in bringing this architecture to enterprise CRM: each company works in its own org, but underneath it shares the same software core as every other customer in the world, which lets everyone receive automatic upgrades three times a year without installing anything.

The multi-tenant concept solves an economic problem before a technical one. Maintaining a dedicated software installation per customer (servers, patches, upgrades, monitoring) is expensive and does not scale. By sharing a single codebase and common infrastructure across thousands of customers, the provider spreads that cost and can offer the service for an affordable monthly subscription. That cost efficiency is largely what made the SaaS explosion of the last twenty years viable.

How information is isolated

The obvious question from any IT lead is: if everyone shares the same database, how do you guarantee my data does not mix with another company's? The answer is logical isolation. In the Salesforce model, every row of every table carries an organization identifier (an OrgID) that acts as an invisible tag. The platform engine automatically and mandatorily adds a filter on that identifier to every query, so a company can never read or reach another's records. Isolation does not depend on the developer's good intentions: it is hardwired into the platform core.

The three common variants

Not every multi-tenant architecture isolates data the same way. In practice, three approaches coexist, each with a different balance between efficiency and isolation:

• Shared database, shared schema: all tenants live in the same tables and are separated by an identifier column (the Salesforce model). It is the most cost-efficient and the one that scales best.
• Shared database, separate schemas: a single database, but each tenant has its own set of tables. More isolation, slightly less efficiency.
• Separate database per tenant: each customer has its own database. It is the closest to single-tenant; maximum isolation, but more expensive to operate.

Multi-tenant vs. single-tenant

Why it matters to the business, not just to IT

For a buying committee evaluating a platform like Salesforce, multi-tenancy has very concrete consequences. First, you never fall behind: the three annual releases reach everyone at the same time, with no upgrade projects or maintenance windows of your own. Second, you pay for actual use through a subscription, instead of investing up front in licenses and infrastructure. Third, security and compliance (certifications, vulnerability patches) are handled by the provider for everyone at once, a level of investment a single company could rarely afford on its own.

The tradeoff is shared limits. Because many customers use the same infrastructure, the platform enforces consumption caps so that no tenant degrades the experience of the others: in Salesforce, this takes the form of governor limits, rules that cap how many records an operation processes or how many queries a transaction runs.

A concrete example in Argentina

Think of a consumer goods distributor headquartered in Córdoba that adopts Salesforce for its sales force. It shares the same platform with thousands of companies around the world, but its customer, order and pricing data lives isolated in its own org. When the Spring release arrives, its team wakes up to new Sales Cloud features without touching a server. And if a developer writes an automation that tries to process 60,000 records in one go, the platform stops it through governor limits, protecting both that distributor and the rest of the tenants.

Common mistakes when reasoning about multi-tenancy

A frequent misunderstanding is believing that "sharing a database" means "less secure data." In serious architectures, the opposite is true: isolation is more controlled and audited than in many custom installations. Another mistake is assuming that multi-tenancy means zero customization. Salesforce solves this with a metadata-driven model: each org defines its fields, objects and rules as configuration, not as changes to the shared code, so every company experiences the platform as its own without breaking the common core. Confusing that configuration-based customization with custom development leads to poor architecture decisions.