Multi-Tenant

Picture a large apartment building. All residents share the foundation, heating, stairwell, and power connection. Yet each has their own apartment with their own key, and no one sees the neighbors' furniture. That is exactly how multi-tenant software is built: a single system runs on shared machines, but many different customers use it at the same time without seeing anything of each other. Each of these customers is called a tenant in technical jargon. The opposite would be a separate house for each: a dedicated installation on dedicated machines for every customer.

Why almost every online service is built this way

The main reason is money. Machines that belong to a single customer sit nearly idle most of the time. If a hundred customers share the same infrastructure, their load peaks even each other out. The provider therefore needs only a fraction of the hardware and can sell the service for a few euros a month.

The second reason is maintenance. In a shared system there is only one program version. A security update is rolled out once and takes effect immediately for everyone. With a thousand separate installations, a team would have to do the same thing a thousand times, and some customers would get stuck on outdated versions. This explains why online services often gain new features overnight without anyone needing to download anything.

The price for this is dependency. If the shared system fails, all customers are affected at the same time. Such outages at major cloud providers regularly knock out thousands of companies at once. In addition, a single customer with an extremely high volume of requests can slow down the others. Experts call this the noisy neighbor.

How separation between tenants is achieved

Technically, every record is given an identifier that indicates the tenant. Every request to the database is automatically supplemented with this identifier. If a user from Company A queries their invoices, the system only delivers rows carrying Company A’s identifier. Company B’s data sits in the same table but is never included.

There are stricter variants. Some providers give each customer their own database but share the computing power. Others separate only the storage and let a shared program access it. The stricter the separation, the more expensive the operation. Companies with sensitive data, such as hospitals or banks, often deliberately pay more for stronger isolation.

The sore point is always a programming error in this filtering. If a single query forgets the tenant identifier, a customer suddenly sees someone else’s data. Such mishaps are rare, but they rank among the most severe mistakes a software company can make. That is why, in well-built systems, the separation is not programmed individually for every query but enforced centrally.

From Google Docs to the AI interface

Practically every service used in a browser works this way. Google Docs, Spotify, Instagram, and the school platform that holds grades all run for millions of users on the same machines. Enterprise software such as Salesforce or Microsoft 365 also follows this pattern. The English acronym SaaS, meaning Software as a Service, usually refers to exactly these kinds of shared systems.

In the AI world, the term comes up especially often. Anyone using a language model through an interface shares the expensive graphics processors with many others. Requests from different companies are batched and computed together, which drives down the cost per request. Large customers, on the other hand, sometimes book dedicated capacity, meaning hardware reserved exclusively for them.

In the news, Multi-Tenant usually appears in two contexts. Either it concerns data protection and the question of whether company data is safe enough in a shared system. Or it concerns outages, where a fault in a shared facility hits many companies at the same time. A common misconception, incidentally, is that shared automatically means insecure. What matters is not the shared hardware, but how cleanly the separation was implemented.