A multi-tenant system can be used by many customers and for each of them it looks like they are the only ones. Think about AWS, for example: the account is isolated from all other accounts, and apart from the account ID there is no indication that anybody else is using that platform.

The obvious reason is that there is only one deployment and not one per customer. But I found that even if I needed to design a system that is only used by one customer I would design it with support for multiple tenants.

This is a tradeoff, of course: every feature makes the system more complex and the cost of complexity tends to accumulate over time. This is especially true for multi-tenancy as that affects almost everything.

So, why do I still prefer to add that complexity?

Running integration tests is easily parallelizable in a multi-tenant system: since each tenant is separated from the others, all tests can run in parallel. The tests are simple: create a tenant, run the test, delete the tenant. The only extra thing is to clean up the junk if a test exits abruptly. I found that a naming convention that encodes an expiration time works well: a script can periodically run and clean up the expired ones. For example, the tenants that tests create all follow __TEST_AUTODELETE_<expiration>__ pattern.

Also, it enables production monitoring that mimics real user behavior. Instead of looking at charts and trying to figure out which one is going to go up or down during an incident, you can write a script that logs in as a tenant, runs some scenarios, and reports success/failure. All this without worrying about breaking something for real clients.

Then it allows sales (and developers) to use the production system. Create a tenant for them and they are free to demo the features.

Finally, requirements can change. I find it likely that it is going to be needed to put more tenants into a single system as the business evolves.

Lately, I’ve been looking into row-level security in Postgres and I believe multi-tenancy can be set up in a non-intrusive way. I’m still formulating my thoughts on this, but it seems that the whole complexity of adding multi-tenancy can be contained in a limited amount of code since the tenant ID can be set in a central place and then filtering and access control are handled by the database instead of every single query. I’ll explore this topic in the future, but it seems like a good approach.