InteopleAlmost every product we build for partners — and our own platforms like EduNation, which serves many schools from one system — is multi-tenant. One running application, many customers, each seeing only their own world. It sounds simple. The simplicity is the trap: the decisions that make multi-tenancy work are made early, are expensive to reverse, and are mostly invisible until the day they aren't.
What multi-tenancy really means
A tenant is a customer organisation — a school, a clinic, a company — and everyone within it. Multi-tenancy means a single deployment of your software serves all of them, sharing infrastructure while keeping each tenant's data and configuration strictly separate. The alternative, spinning up a separate stack per customer, is operationally brutal at any real scale: every deploy, patch and migration multiplies by your customer count.
The entire discipline comes down to one question, asked over and over: how do you share resources for efficiency while guaranteeing isolation for safety?
Three data isolation models
There are three classic ways to partition tenant data, and they sit on a spectrum from cheap-and-shared to expensive-and-isolated.
1. Shared schema, shared database
Every tenant's rows live in the same tables, separated by a
tenant_id column. This is the most cost-efficient
and the easiest to operate — one schema, one migration, one
connection pool. It's where most SaaS should start. The risk is
concentrated in one place: a single query that forgets its
tenant filter leaks data across customers. That risk is
manageable, but only with discipline (see below).
2. Shared database, separate schemas
Each tenant gets its own schema within a shared database. Stronger logical separation, and easier to back up or export a single tenant — at the cost of running migrations across many schemas and watching connection overhead as tenant count climbs. A reasonable middle ground for a moderate number of larger tenants.
3. Database per tenant
Full physical isolation. The strongest security and the cleanest "noisy neighbour" story, and sometimes a hard compliance requirement for regulated or enterprise customers. It's also the most expensive to run and automate. We reserve it for tenants who genuinely require it, rather than paying its cost for everyone.
There's no universally correct model — only the right trade-off for your customers' size, count and compliance needs. Most products want a shared-schema default with a path to dedicated isolation for the tenants who need it.
Enforcing isolation you can trust
In a shared-schema design, "we'll just remember to filter by
tenant" is not a security model. One missed
WHERE clause is a breach. So isolation has to be
enforced where it can't be forgotten:
- Row-level security in the database — Postgres RLS policies that filter by the current tenant automatically, so even a query that forgets the filter returns nothing cross-tenant.
- Tenant context set once, per request — resolved at the edge from the authenticated session and threaded through every query, never passed in by the client.
- A data-access layer that refuses untenant-scoped queries — make the safe path the only path, so isolation isn't a thing each developer must remember.
- Tests that actively try to cross tenants — automated checks that assert tenant A cannot read tenant B, run on every change.
Defence in depth is the point: application checks and database-enforced policies, so a bug in one layer doesn't become a leak.
The noisy-neighbour problem
Sharing infrastructure means one tenant's spike can degrade everyone else. A single customer running a massive report shouldn't slow the whole platform. Containing that is part of the architecture, not an afterthought:
- Per-tenant rate limits and quotas so no one tenant can monopolise shared capacity.
- Heavy or async work off the request path — queues and background workers, isolated per tenant where it matters.
- Connection and resource pooling tuned so one tenant can't exhaust the pool.
- Per-tenant observability so you can see which tenant is driving load before it becomes an incident.
Key takeaways
- Your tenancy model sets your cost and security ceiling — choose it deliberately.
- Shared-schema is the right default for most SaaS; isolate physically only where required.
- Enforce isolation in the database (RLS), not just the application.
- Set tenant context server-side, never trust it from the client.
- Plan for noisy neighbours and per-tenant scaling from the start.
Scaling without a rewrite
The goal is an architecture that grows with you instead of forcing a rebuild at the worst possible moment. A pattern that serves us well: start on a shared schema for efficiency, but design so that an individual tenant can be lifted to a dedicated database or schema when they grow large or demand strict isolation — without re-architecting the whole platform. That means keeping the tenant boundary explicit everywhere from day one, so "move this tenant" is a migration, not a rewrite.
The same per-tenant boundary that gives you security also gives you flexibility — per-tenant configuration, feature flags, data residency, even pricing tiers — because every dimension of the system already knows which tenant it's serving. Get the boundary right early, and multi-tenancy stops being a liability and becomes the thing that lets one team serve thousands of customers well.
