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.