Multi-tenancy for small teams

The version of this that works is simpler than the version most people imagine. Most advice about multi-tenancy assumes a team that does not exist at your size. Here is the version that does not.

Architecture is the set of decisions that are expensive to reverse, which is the only reason they deserve the name. Anything you cannot measure here, you are deciding by taste, which is fine as long as everyone knows it.

What to keep

Decide early whether tenants share a database or not. Getting it slightly wrong is survivable. Ignoring it entirely is not. Budget a little time for it every quarter and it never becomes a project of its own.

What to drop

Process that exists to coordinate ten people is overhead when there are two of you. There is a version of this that is over-engineered, and it is worth avoiding.

Where to start

Noisy neighbours become a support problem before an engineering one. The cost of getting this wrong is rarely visible on the day it happens. If two people in the business would answer this differently, that gap is the actual problem.

In practice

The right architecture for a team of three is the wrong one for a team of thirty, and vice versa. 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

If any of that sounds like a description of your current setup, it is fixable.