Multi-Tenant Defintions

[codingforentrepreneurs]

Single Tenant

Core idea: same app code, same database, all users.
Isolation Level: 1 out of 3
Simplicity Score: 3 out of 3

Data must be filtered on a per-user basis. Incorrect filter, data can be shared with the wrong user. A standard Django project defaults to a single-tenant architecture.

Django Groups make it possible to have multi-tenant-like features but it's not actually considered multi-tenant.

Multi-Tenant

Dedicated user auth + data isolation = multi-tenant

Multi-tenant is a technical configuration that helps isolate user data while using the same codebase and the same servers to run the app for all. While leaks are always possible, this type of isolation is often what Enterprises require.

Multi-tenant is where users have users. That's why I like to think of multi-tenacy as the "Enterprise architecture for SaaS" because many businesses need complete admin control over their users' accounts: add, remove, manage new user accounts at-will. Some Enterprises are will to pay extra for advanced features that may not be available otherwise.

From a code perspective, it's going to be mostly the same code as a Single Tenant with two major caveats: migrations and data access. That said, we have two primary options for multi-tenancy: schema-based or database-per-enterprise

Schema-Based Multi-Tenants

Isolation Level: 2 out of 3
Simplicity Score: 2 out of 3
Core idea: same app code, same database, different schemas.

The database process is this: database server -> schema -> tables. This means a single database can have many schemas with many tables.

In standard Django, we use 1 schema to run our project and it defaults to the name "public". Postgres has support for additional schemas which happens to be one of the way we can create multi-tenancy in Django. django-tenants does this.

If you don't know database tech well, database schemas are confusing. For a long time, I thought that database servers could only have database tables. But, if you think of a single database server like your personal Google Sheets account, it might be helpful. One single database server can have thousands of schemas (e.g. Google Sheets Documents). Each schema can have thousands of tables (e.g. the sheet tabs on the bottom). Each table can have billions (trillions?) of rows.

Using database schemas for multi-tenancy can be a huge unlock because it can be added (or adjusted) at anytime.

Your Django project can use the "public" schema for years and years. Then you get an enterprise customer who needs multi-tenancy, you can add this after the fact as we discuss in the course.

Database-per-Enterprise Multi-Tenants

Isolation Level: 3 out of 3
Simplicity Score: 1 out of 3
Core idea: same app code, different database, same schema name (e.g. "public").

In short, provision a new database for every enterprise customer. This is a technical nightmare. Managing many database servers to achieve multi-tenancy can cause a lot of issues.

Imagine having 1 migration go wrong, when you have 1 database server, the migration fixes are still challenging but doable. If you have 100 database servers, there goes your weekends for the next 4 years. Kidding aside, managing a lot of databases and your code is not a trivial task.

Even using a tool like Neon postgres can remove a lot of the issues but it still isn't easy.

The course unpacks how.