What is multi-tenancy?
One customer's query returning another customer's data isn't a bug report. It's a breach notice.
Multi-tenancy
multi-tenant architecture
Multi-tenancy is a setup where one app serves many separate customers, called tenants, from shared infrastructure. Each tenant's data stays walled off from every other tenant, even though the code, servers, and often the database are shared.
The opposite is single-tenancy: one deployment per customer, each with its own database and often its own servers. Nothing is shared, so it's easy to reason about. But the cost multiplies with every signup, and that stops scaling fast.
Most SaaS products end up multi-tenant, because they have no other choice. A thousand customers on a thousand separate deployments is not a business you can run. So the real question is how to share servers without one tenant's request ever touching another tenant's rows.
Isolation is checked on every query, not switched on once
The common approach is a shared database with a tenant_id column on every table. Every query filters by it. But queries get written in a lot of places: API routes, background jobs, admin tools, one-off scripts. And now, AI features that pull data from a vector store.
Miss the filter in any one of those places and a customer sees another customer's data. Postgres row-level security can enforce the filter at the database itself. That way, no single code path has to remember it on its own.
A separate schema per tenant, or a separate database per tenant, trades that risk for more work to run. Every migration now runs once per tenant instead of once. Which model fits depends on how many tenants you have, and how sensitive their data is.
- 01Shared database, shared schema, tenant_id on every row. Cheapest to run, and safety depends on every query remembering the filter.
- 02Shared database, separate schema per tenant. The database itself holds the wall up, at the cost of a migration step that now runs once per tenant.
- 03Separate database per tenant, shared app servers. The strongest wall short of full single-tenancy, usually kept for big or regulated customers.
- RequestArrives tagged with a tenant.
- AuthConfirms who the tenant is.
- QueryMust filter by tenant on every table.
- RetrievalVector search needs the same filter, or it ranks across tenants.
- ResponseOnly this tenant's rows reach the client.
- Background jobRuns with no request in front of it, so the filter has to be explicit.
The database layer is the easy half. Every background job, admin tool, and AI retrieval call has to carry the same tenant filter, and nothing forces that on its own.
Common questions
01Is multi-tenancy the same as a shared database?
No. A shared database is one common way to build multi-tenancy, but it is not the definition. Multi-tenancy just means one deployment serves many customers, each walled off from the rest. You can get there with a shared database and a tenant_id filter, a schema per tenant, or a database per tenant on shared servers.
02When does single-tenancy make more sense than multi-tenancy?
It makes sense with only a few customers, each needing data-location or compliance rules a shared setup can't meet. It also fits when customers pay enough that a dedicated deployment costs little next to the contract. Most SaaS products with dozens or hundreds of customers stay multi-tenant, because the alternative does not scale.
03How is multi-tenancy different from RBAC?
Multi-tenancy separates customers from each other. Role-based access control separates users inside one customer's account, deciding what an admin can do that a normal user can't. Most products need both. Tenancy keeps Customer A out of Customer B's data. RBAC stops a junior user inside Customer A from doing what only an admin should.
04Does adding AI features change how multi-tenancy has to work?
Yes, mainly in the retrieval layer. A vector database query has to filter by tenant before it ranks results by similarity, the same way a SQL query filters before it joins. Skipping that step is the most common way tenant isolation breaks once a product adds an AI agent or search feature.
