Multi-tenancy

What it means

Multi-tenancy means a single running copy of your application serves many customers, called tenants, at the same time. They share the code, the servers and often the same database. Each sees only their own data, as if they had an application to themselves.

NIST's definition of cloud computing describes the same idea as resources pooled to serve multiple consumers. The convenience is cost and speed. The price is that separation is no longer provided by separate machines. Your own code has to enforce it, on every request.

Why it matters

If separation fails, one customer sees another's data. For a software business that is close to the worst thing that can happen: contracts, trust and sometimes regulatory duties all depend on it. One flawed query can affect hundreds of customers at once, and nobody on your side may notice until a customer reports it.

Buyers ask about it directly in security questionnaires. How you keep tenants apart, and how you know it works, is often the longest answer you write and the one a careful buyer reads twice before deciding whether to trust you with their data.

How it shows up

The usual design puts a tenant identifier on each row and filters by it. The filter is added by hand in each query, or enforced centrally, or by the database itself using row-level security. The more it depends on developers remembering, the more often it is forgotten.

Trouble shows up in background jobs that run without a tenant context, search indexes and caches shared across customers, export features, and admin screens. Test by creating two tenants and checking what one account can reach that belongs to the other. See also tenant isolation.