Multi-Tenancy

Think of it as

Read the three models as a single dial between *cheap and dense* and *isolated and expensive*, and place your product on it using the requirements you actually have rather than the ones you can imagine. Shared schema is one row set with a discriminator column, so a thousand tenants cost one migration, one connection pool and one backup — but every single query must be filtered, and the isolation is only as good as the code that remembers to do it. Schema-per-tenant keeps one database and one connection pool while giving each tenant its own tables, so a query that forgets the filter usually finds nothing rather than someone else's data; the cost is that migrations now run N times and a schema catalogue with tens of thousands of tables becomes its own operational problem. Database-per-tenant is the strongest: separate backups, separate restores, a genuinely per-tenant blast radius, and the ability to put one customer in another region — paid for with N connection pools, N migration runs, and cross-tenant reporting that is no longer a query. The identification decision looks smaller and is not, because it determines what an attacker can influence. Anything the client supplies — a subdomain, a path segment, an `X-Tenant-Id` header — is a *claim*, and the only safe use of a claim is to check it against something the server already knows: this authenticated user's membership. Deriving the tenant from the session alone avoids that entirely but forfeits shareable per-tenant URLs. Deriving it from the URL and then verifying membership gives you both, and the verification is the load-bearing half. The order matters too — resolve the tenant before authorisation runs, so every permission check downstream is already scoped, and fail closed when no tenant can be established rather than defaulting to a first, a last, or an unfiltered view of everything.

Think of it as

Treat every path that can reach a row as a place the filter must already be applied, and then ask which of those paths your defence actually covers. The obvious one is a direct query, and a custom manager whose `get_queryset()` filters by the current tenant handles it well: `Invoice.objects.all()` returns only this tenant's invoices, and code that never writes a filter is still safe. The non-obvious one is relationship traversal, and this is where confidence outruns coverage. Django resolves related objects through the *base* manager, and the documentation says outright that base managers are not used when querying on related models or when accessing a one-to-many or many-to-many relationship — so `some_invoice.line_items.all()` and `Payment.objects.filter(invoice__reference=…)` do not pass through your filtering manager at all. If the object you started from belongs to another tenant, the traversal returns their data. That is why object lookup must be scoped at the point of lookup, and why the manager is a convenience rather than a boundary. The third surface is authorization, and the rule is that a permission is never global — "can view invoices" is meaningless without "which tenant's". Checking a role without also checking membership of *this* tenant means a legitimate admin of tenant A passes a permission check while operating on tenant B. The fourth is caching, and it is the one that leaks without any database query being wrong at all: a cache key of `dashboard_stats` is shared by every tenant, so whoever populates it first serves it to everyone else. Every key, every fragment cache, every memoised value needs the tenant in it. The strongest answer, where the database supports it, is to stop relying on application code entirely. PostgreSQL row-level security enforces the predicate in the database, and when RLS is enabled with no policy the default is deny — nothing is visible. That inverts the failure mode: forgetting the filter returns nothing instead of returning someone else's rows. Note one sharp edge if you adopt it — table owners normally bypass RLS unless the table is set to `FORCE ROW LEVEL SECURITY`, and Django's migration user is often the owner.

Think of it as

The unifying idea is that in single-tenant software these three things live in the code and the deployment, and in multi-tenant software they all move into data. Limits move first, and the reason is the noisy-neighbour failure: a shared pool means one tenant's spike is felt as latency by everyone, so the limit is not there to punish them but to keep their spike from becoming everyone's incident. That means limits have to be scoped per tenant, not per user or per IP — a hundred users at one customer are one bill and one blast radius — and they need to cover the resources that are actually scarce, which is usually worker time and database connections rather than request count. A separate queue per plan tier is often more effective than any rate limit, because it bounds the damage structurally: a slow bulk job cannot starve interactive work if it cannot reach those workers. Configuration moves next, and the trap is doing it in settings. A `TENANT_OVERRIDES` dictionary in `settings.py` makes every plan change a deploy, cannot be edited by support, and grows a branch per customer. A row on the tenant — or a small typed config model with defaults — makes the same change a database write, auditable and instant, and keeps the code path identical for all tenants. Resolve it as a chain: an explicit per-tenant value, then the plan default, then the system default, so a missing value is never a crash and never a surprise. Audit is the third, and multi-tenancy changes what an entry has to contain. Every record needs the acting user, the tenant *the action was performed on*, and the tenant the actor belongs to — because those differ precisely in the cases that matter: support staff acting on a customer's behalf, and impersonation. Impersonation deserves being explicit about: when a support engineer views a customer's account, the audit entry must record both identities, or the log says the customer did it themselves. And the log has to be scoped like everything else, since a tenant reading their own audit trail must not see anyone else's — an audit log is data, and it obeys the same isolation rule as the rest.