Python / Django multi-tenancy solution

kotyy picture kotyy · Oct 7, 2013 · Viewed 9k times · Source

I could use some help creating a plan of attack for a project I'm working on.

Imagine that the site is for a group that oversees regional sales offices, distributed around the world. The purpose of this project is to let superusers spin up a new sub-site specific to each and every office, at a fast pace -- sites are added on a frequent basis. The office sub-sites should be wholly contained with "admin" users specific to that sub-site and should be user-friendly CMS. A superuser should be able to step in and manage all of these office sub-sites.

In addition to the self-contained office sub-site instance, there is also a need for each sub-site to manage contacts, leads, etc and store this in one central area for the superusers.

I've done a few sites using Django, but never anything multi-tenant. I'd like suggestions for technologies to use or tutorials/documentation that might be helpful.

Requirements:

  1. Each sub-site uses the same source (templates, JS, available features, etc), but can be modified to reflect custom content within the templates.
  2. Assigned subdomains (with an option of using a fully qualified domain) per sub-site, configured within the project, not in a hardcoded settings file.
  3. Sub-site specific user access controls, in addition to superusers who can access all sub-sites.
  4. The ability to provide an "independent" CMS for each sub-site. i.e., A sub-site admin only sees their content. My preference for this project would be django-cms, but I'm open to suggestions.
  5. Support for apps that pool the data from all the sub-sites, but limit sub-site "admins" to only viewing their records into that app.

Considering the above, what approach would you recommend? I am open to reconsidering technologies, but I would like to stick with Python.

Answer

Maciej Gol picture Maciej Gol · Oct 7, 2013

There is a great app called django-tenant-schemas that uses PostgreSQL schemas mechanism to create multi-tenancy.

What you get is specyfing SHARED_APPS that contain objects shared across all the schemas (sub-sites), and TENANT_APPS that contain objects specific for a sub-site, i.e. users, records etc. The schemas are completely isolated from each other.

Each PostgreSQL schema is tied to a domain url, so that middleware checks the HOST part of the request and sets the db connection's schema to appriopriate one.

In addition, it allows you to define a PUBLIC_SCHEMA_URLCONF which allows you to specify urlconf file for public schema - the meta site that is not tied to any sub-site.