Introduction to multi-tenant apps with django

What are multi-tenant apps

Multi-tenancy is an architecture in which a single instance of a software application serves multiple customers.

But then you might be wondering, "Don't all apps do this? What makes this so special?"

The answer to this lies in the fact that multi-tenant applications allow you to serve multiple customers with one install of the application. Each customer has their data completely isolated in such an architecture. Each customer is called a tenant.

Tenants may be given the ability to customize some parts of the application, such as the color of the user interface (UI) or business rules, but they cannot customize the application's code.

Approaches to multitenancy

There are various approaches to multi-tenancy. Key among them are:

1. Shared database with a shared schema.
2. Shared database with isolated schemas.
3. Isolated database with an isolated schema.
4. Completely isolated tenants.

For this series, we'll be going by the Shared database with isolated schemas approach.
Should you wish to know more about the rest, check out this awesome book by agiliq.

Shared database with isolated schemas

In this method, a single database instance keeps the tenant's records. As opposed to linking every tenant's data by a foreign key, as we would normally do, this is common in method 1 indicated previouslyShared database with a shared schema,
we create a new schema for every new tenant.

Advantages of multi-tenancy

Multi-tenant applications are especially useful when it comes to building Software As A Service(SAAS) products.
Using this approach instead of single-tenancy, a number of advantages present themselves. Key among them:

1. Affordable cost: Having multiple customers means that the cost of the environment(hosting, databases, and dev time) is shared. Those savings in turn are typically transferred to the cost of the Software.
2. Adding a new customer is easier: in single-tenant apps, a fresh installation of the app is required every time a new customer comes on to the platform. With multi-tenancy, it happens in a matter of seconds using an API call.
3. Convenience in maintaining a single application: As mentioned above, using the single-tenant approach means having multiple instances of the same application. You can imagine the nightmare of maintaining and updating all those instances as your customers grow. Good problems to have of course since you are obviously doing something right 😄, but nonetheless, it will result in a lot of time and resource wastage.

Live Demo

We'll be working towards building a multi-organizational expense tracker. The live demo can be found here.

Backend code repo

The backend code is written in python(django) and deployed using docker-compose.

The repo has multiple branches representing the application at various stages. We'll move step by step to avoid information overload.

Frontend Code repo

The frontend was built with vue.js, specifically nuxt.js, and deployed using pm2

In the coming posts, we'll get hands-on by building the functional full-stack application. By the end of the series, hopefully, you should be able to build similar systems.

Comments

[Shadrack Danford Kamenya]

A very insightful blog man. Keep good work alive. Can you kindly create a tenant-schema package as a stand alone? Thanks

[Lewis kori]

Hey, thank you.
I'm glad you found the content useful.

There's a package already called django-multitenant which uses the 1st approach, Shared database with a shared schema.. So maybe I could make one with my approach if I get the time, Shared database with isolated schemas :)

I've also replied to the comment you left on my website.
Here's the reply

[Shadrack Danford Kamenya]

Thank you Lewis

I would appreciate if you make shared database with isolated schemas.

Thank you for making helpful content