Skip to main content

PyPi version PyPi downloads Python versions CI PostgreSQL

This application enables django powered websites to have multiple tenants via PostgreSQL schemas. A vital feature for every Software-as-a-Service website.

Django provides currently no simple way to support multiple tenants using the same project instance, even when only the data is different. Because we don’t want you running many copies of your project, you’ll be able to have:

  • Multiple customers running on the same instance

  • Shared and Tenant-Specific data

  • Tenant View-Routing

What are schemas

A schema can be seen as a directory in an operating system, each directory (schema) with it’s own set of files (tables and objects). This allows the same table name and objects to be used in different schemas without conflict. For an accurate description on schemas, see PostgreSQL’s official documentation on schemas.

Why schemas

There are typically three solutions for solving the multitenancy problem.

  1. Isolated Approach: Separate Databases. Each tenant has it’s own database.

  2. Semi Isolated Approach: Shared Database, Separate Schemas. One database for all tenants, but one schema per tenant.

  3. Shared Approach: Shared Database, Shared Schema. All tenants share the same database and schema. There is a main tenant-table, where all other tables have a foreign key pointing to.

This application implements the second approach, which in our opinion, represents the ideal compromise between simplicity and performance.

  • Simplicity: barely make any changes to your current code to support multitenancy. Plus, you only manage one database.

  • Performance: make use of shared connections, buffers and memory.

Each solution has it’s up and down sides, for a more in-depth discussion, see Microsoft’s excellent article on Multi-Tenant Data Architecture.

How it works

Tenants are identified via their host name (i.e tenant.domain.com). This information is stored on a table on the public schema. Whenever a request is made, the host name is used to match a tenant in the database. If there’s a match, the search path is updated to use this tenant’s schema. So from now on all queries will take place at the tenant’s schema. For example, suppose you have a tenant customer at http://customer.example.com. Any request incoming at customer.example.com will automatically use customer‘s schema and make the tenant available at the request. If no tenant is found, a 404 error is raised. This also means you should have a tenant for your main domain, typically using the public schema. For more information please read the setup section.

What can this app do?

As many tenants as you want

Each tenant has its data on a specific schema. Use a single project instance to serve as many as you want.

Tenant-specific and shared apps

Tenant-specific apps do not share their data between tenants, but you can also have shared apps where the information is always available and shared between all.

Tenant View-Routing

You can have different views for http://customer.example.com/ and http://example.com/, even though Django only uses the string after the host name to identify which view to serve.

Magic

Everyone loves magic! You’ll be able to have all this barely having to change your code!

Installation

Install django-tenant-schemas with your preferred PostgreSQL client:

# For psycopg2
pip install django-tenant-schemas[psycopg2]

# For psycopg
pip install django-tenant-schemas[psycopg]

Setup & Documentation

This is just a short setup guide, it is strongly recommended that you read the complete version at django-tenant-schemas.readthedocs.io.

Your DATABASE_ENGINE setting needs to be changed to

DATABASES = {
    'default': {
        'ENGINE': 'tenant_schemas.postgresql_backend',
        # ..
    }
}

Add the middleware tenant_schemas.middleware.TenantMiddleware to the top of MIDDLEWARE, so that each request can be set to use the correct schema.

MIDDLEWARE = [
    'tenant_schemas.middleware.TenantMiddleware',
    #...
]

Add tenant_schemas.routers.TenantSyncRouter to your DATABASE_ROUTERS setting, so that the correct apps can be synced, depending on what’s being synced (shared or tenant).

DATABASE_ROUTERS = (
    'tenant_schemas.routers.TenantSyncRouter',
)

Add tenant_schemas to your INSTALLED_APPS.

Create your tenant model

from django.db import models
from tenant_schemas.models import TenantMixin

class Client(TenantMixin):
    name = models.CharField(max_length=100)
    paid_until =  models.DateField()
    on_trial = models.BooleanField()
    created_on = models.DateField(auto_now_add=True)

Define on settings.py which model is your tenant model. Assuming you created Client inside an app named customers, your TENANT_MODEL should look like this:

TENANT_MODEL = "customers.Client" # app.Model

Now run migrate_schemas to sync your apps to the public schema.

python manage.py migrate_schemas --shared

Create your tenants just like a normal django model. Calling save will automatically create and sync/migrate the schema.

from customers.models import Client

# create your public tenant
tenant = Client(domain_url='tenant.my-domain.com',
                schema_name='tenant1',
                name='My First Tenant',
                paid_until='2014-12-05',
                on_trial=True)
tenant.save()

Any request made to tenant.my-domain.com will now automatically set your PostgreSQL’s search_path to tenant1 and public, making shared apps available too. This means that any call to the methods filter, get, save, delete or any other function involving a database connection will now be done at the tenant’s schema, so you shouldn’t need to change anything at your views.

You’re all set, but we have left key details outside of this short tutorial, such as creating the public tenant and configuring shared and tenant specific apps. Complete instructions can be found at django-tenant-schemas.readthedocs.io.

Release files for django-tenant-schemas 2.0.0

For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.

Source distribution (sdist)

Source distribution for django-tenant-schemas 2.0.0
File Size Uploaded
django_tenant_schemas-2.0.0.tar.gz 69.5 kB Details

Built distribution (wheel)

Table of built distributions (wheels) for django-tenant-schemas 2.0.0
File Interpreter ABI Platform
django_tenant_schemas-2.0.0-py3-none-any.whl Python 3 none any Details

Total release size: 115.9 kB

Release files / django_tenant_schemas-2.0.0.tar.gz

Download URL django_tenant_schemas-2.0.0.tar.gz
Size 69.5 kB
Tags Source
SHA-256 checksum
How to use checksums
5696fab7090b00e6b4935cd37f4581ee9d3914f0d838306149c84fd4cf6624cc
BLAKE2b-256 checksum
How to use checksums
fcdc88c02fc818f2f97ce07d11a757dbc2c3f1985b189da6f7daafd64d68ac08
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
No
Uploaded via uv/0.8.13

Release files / django_tenant_schemas-2.0.0-py3-none-any.whl

Download URL django_tenant_schemas-2.0.0-py3-none-any.whl
Size 46.4 kB
Tags Python 3
SHA-256 checksum
How to use checksums
4220b91edefa8e03d3285cc097b01168c9b629e19e2e3b6ef39b7496cd62c8aa
BLAKE2b-256 checksum
How to use checksums
87a0739c830ebd18b888b992bf96289581ded181696e8b13d5ba4c708f977297
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
No
Uploaded via uv/0.8.13

Release history Release notifications | RSS feed

This release

2.0.0 This release

2 release files

1.12.0

2 release files

1.11.0

2 release files

1.10.0

3 release files

1.9.0

1 release file

1.8.0

1 release file

1.7.0

1 release file

1.6.10

1 release file

1.6.9

1 release file

1.6.8

1 release file

1.6.4

1 release file

1.6.3

1 release file

1.6.2

1 release file

1.6.1

1 release file

1.6.0

1 release file

1.5.8

1 release file

1.5.7

1 release file

1.5.6

1 release file

1.5.5

1 release file

1.5.4

1 release file

1.5.2

1 release file

1.5.1

1 release file

1.4.8

1 release file

1.4.7

1 release file

1.4.6

1 release file

1.4.5

1 release file

1.4.4

1 release file

1.4.1

1 release file

1.3.2

1 release file

1.3.1

1 release file

1.2.0

1 release file

1.1.5

1 release file

1.1.3

1 release file

1.1.2

1 release file

1.1.1

1 release file

1.1.0

1 release file

1.0.3

1 release file

v1.0.1

1 release file

1.0.1

1 release file

1.0.0

1 release file

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page