Multi-tenancy, explained without the jargon

The gap between knowing this and actually doing it is where most teams lose ground. Here is multi-tenancy without the vocabulary that usually surrounds it.

The right architecture for a team of three is the wrong one for a team of thirty, and vice versa. Budget a little time for it every quarter and it never becomes a project of its own.

The short version

Decide early whether tenants share a database or not. The reasoning matters more than the rule, because the rule has exceptions. If it only works because one person remembers to do something, it does not work yet.

Why people complicate it

Most of the confusion comes from tooling rather than from the idea itself. The reasoning matters more than the rule, because the rule has exceptions.

Isolation is a security requirement, not a preference. The cost of getting this wrong is rarely visible on the day it happens. The failure mode is not doing it wrong, it is doing it once and assuming it stays done.

Where to go from here

Noisy neighbours become a support problem before an engineering one. The cost of getting this wrong is rarely visible on the day it happens. Most teams find the first pass takes an afternoon and the maintenance takes minutes a month.

What this looks like day to day

Most systems fail at the seams rather than inside any one component. Three things worth confirming about multi-tenancy before you move on:

• Someone can say what the current setup is without going to look
• Isolation is a security requirement, not a preference — and you know whether that is true here
• There is a way to tell whether the last change to this helped

Worth checking on your own setup before it becomes someone else's problem to fix.