Tying it all together

Launching new tenants

In the previous chapters, we have worked with a hardcoded list, of two tenants, thor and potter. Our code looked like this

code-block:: python

def get_tenants_map():
return {“thor.polls.local”: “thor”, “poter.polls.local”: “potter”}

In a real scenario, you will need to launch tenants, so the list of tenants can’t be part of the code. To be able to launch new tenants, we will create a Tenant model.

code-block:: python

class Tenant(models.Model):
name = models.CharField(max_length=100) schema_name = models.CharField(max_length=100) subdomain = models.CharField(max_length=1000, unique=True)

And your get_tenants_map will change to:

code-block:: python

def get_tenants_map():
return dict(Tenant.objects.values_list(“subdomain”, “schema_name”))

You would need to make similar changes for a multi DB setup, or orchestrate launching new containers and updating nginx config for multi container setup.

A comparison of trade-offs of various methods

Until now, we had looked at four different ways of doing multi tenancy, each with some set of trade-offs.

Depending upon how many tenants you have, how many new tenants you need to launch, and your customization requirements, one of the four architectures will suit you.

Method Isolation Time to launch new tenants Django DB Compatibility
Shared DB and Schema Low Low High (Supported in all DBs)
Isolated Schema Medium Low Medium (DB must support schema)
Isolated DB High Medium High (Supported in all DBs)
Isolated using docker Complete Medium High (Supported in all DBs)

What method should I use?

While each method has its pros and cons, for most people, Isolated Schema with shared database is the best method. It provides strong isolation guarantees, customizability with minimal time to launch new tenants.