Multi-Tenancy Architecture
In a multi-tenancy architecture, many customers use the same software on the same machines, yet each one only ever sees their own data. This significantly lowers the cost per customer and is the foundation of almost every offering you subscribe to in a browser.
Imagine an apartment building. All residents share the foundation, roof, pipes, and stairwell. Yet each has their own apartment with their own key, and nobody can see into anyone else’s rooms. A multi-tenancy architecture builds software on exactly this principle: a single program runs on shared infrastructure and serves many customers at once. Each of these customers is called, in technical terms, a tenant, and each is strictly shown only their own data. The alternative model would be to build an entirely separate house for every customer — that is, a separate copy of the program on its own machines.
The cost advantage of shared servers
The economic rationale is simple: shared infrastructure is cheaper than duplicated infrastructure. A provider doesn’t have to maintain 5,000 individual installations, just one. A security update is deployed once and immediately applies to all customers. This saves not only on servers but, above all, on staff — and staff is the largest cost block in the software industry.
This is why multi-tenancy is the technical foundation of the Software as a Service business model, that is, software you rent monthly instead of buying once. Only because a new customer barely causes any additional cost does a price of a few euros per user per month work at all. Providers like Salesforce, Microsoft, or Slack calculate exactly this way. You can read it off in annual reports through gross margins: values of 70 to 80 percent are typical and would hardly be achievable with individual installations.
The price of this model is concentrated risk. If the shared infrastructure fails, all customers are affected at once. And a single programming error in data separation can expose another company’s data. Such incidents are rare, but they regularly make headlines.
How tenant data stays separated
The core mechanism is an identifier stored with every record: the tenant ID. With every request, the software checks which customer the logged-in user belongs to. It is then only allowed to return records with the matching identifier. This check is not the user’s responsibility but is hard-wired into the program itself.
In practice, there are three levels of separation. In the strongest form of sharing, all customers reside together in one database, i.e., one large collection of tables. In the middle variant, each customer gets their own tables within the same database. In the weakest form of sharing, each customer gets their own database, while the program itself remains shared. The more strongly resources are shared, the cheaper the operation — but the greater the damage if the separation fails.
A second problem is called the “noisy neighbor” issue. A single customer runs an extremely resource-intensive query and thereby slows down everyone else. To counter this, providers set limits per tenant, such as a maximum number of requests per minute. Large customers with strict compliance requirements are sometimes still given their own environment. This is called single-tenancy, and providers usually charge handsomely for it.
From Google Docs to the ChatGPT API
Practically every service you use in a browser is built to be multi-tenant. Google Docs, Spotify, the school portal, or an online shop builder run for millions of users on the same software. You notice nothing of this, and that is precisely the goal of a successful implementation.
With AI services, this issue is especially sensitive. When many companies use the same interface to a language model, it must be ensured that one customer’s inputs don’t show up in another’s responses. Providers therefore contractually promise that customer inputs do not flow into training. Anyone who has an AI work with their own company documents must additionally isolate the search over these documents per tenant.
In business news, the term usually appears in two contexts. First, when a provider explains why its cost per customer is falling while the customer count rises. Second, after data leaks, when the separation between tenants was flawed. Both show: multi-tenancy is not a technical footnote, but a decision with direct consequences for profit and trust.
