Django Schemata

PostgreSQL schema support for Django projects
Alternatives To Django Schemata
Project NameStarsDownloadsRepos Using ThisPackages Using ThisMost Recent CommitTotal ReleasesLatest ReleaseOpen IssuesLicenseLanguage
Graphene Django4,13839110816 days ago63August 09, 2023136mitPython
Build powerful, efficient, and flexible GraphQL APIs with seamless Django integration.
Drf Yasg3,16529091a month ago62July 20, 2023242otherPython
Automated generation of real Swagger/OpenAPI 2.0 schemas from Django REST Framework code.
Ariadne2,04310353 months ago47June 27, 202350bsd-3-clausePython
Python library for implementing GraphQL servers using schema-first approach.
Drf Spectacular1,8335311 days ago60July 23, 202364bsd-3-clausePython
Sane and flexible OpenAPI 3 schema generation for Django REST framework.
Djangoql816647 months ago62January 26, 202228mitPython
Advanced search language for Django
Django Rest Framework Api Guide400
5 years ago1
Django REST framework API 指南
Django Schema Graph323
5 months ago9March 01, 202014mitPython
An interactive graph of your Django model structure
Django Graphql Apollo React Demo282
5 years ago18Python
Code for a workshop about my Django, GraphQL, ReactJS, Apollo-stack
Django Tenant Users257
a day ago64February 10, 202210mitPython
Adds global user authentication and tenant-specific permissions to django-tenants.
Django Mutant225515 years ago14October 29, 20175mitPython
Dynamic model definition and alteration (evolving schemas)
Alternatives To Django Schemata
Select To Compare

Alternative Project Comparisons


BEWARE! THIS IS AN EXPERIMENTAL CODE! Created this as a proof of concept and never had a chance to test it thoroughly, not speaking about the production run, as our team changed the plans. While I was very excited during coding it, I unfortunately have no use for schemata currently. I'd love to hear how the code is really doing and if you find something that should be fixed, I'll gladly review and pull your patches.

This project adds the PostgreSQL schema support to Django. The schema, which can be seen as a namespace in which any database object exists, allows to isolate the database objects even when they have the same names. You can have same set of tables, indices, sequences etc. many times under the single database.

In case you're not using schemata, your objects lie in the default schema public and because the default search_path contains public, you don't have to care.

Why to care?

It's simple:

  • One code
  • One instance
  • One shared buffering
  • One connection
  • One database
  • One schema for one customer
  • You scale up to the stars

Using schemata can be very useful if you run the Software as a service (SaaS) server for multiple customers. Typically for multiple databases you had single project code, cloned many times and that required strong maintenance effort.

So until recently you were forced to maintain multiple Django instances even when the code did the same things, only the data varied. With the invention of multiple databases support in Django it was possible to use it for SaaS, yet using schemata was found to bring even more advantages.

This code was inspired by the A better way : SaaS with Django and PostgreSQL Schemas blog post and the django-appschema application.

Going underneath

Like django-appschema this project infers the proper schema to switch to from the hostname found in each web request. You're expected to point multiple HTTP domains of your customers handled by your (Apache/WSGI) server to the single Django instance supporting schemata.

Warning: This application was not tested in the multithreading environment, we configure our mod_wsgi to run each Django instance as mutiple separated processes.

Unlike django-appschema, this project seeks for the maximum simplicity (added layer and toolset must be as thin as possible so the data path is clear):

  • Minimalistic code.
  • No hacking of INSTALLED_APPS, syncdb or migrate commands... (they had enough with South).
  • Schema definitions are not stored in the database, but in settings's dict. That allows you to flexibly and uniformly configure the differences between individual domains. django-schemata only requires schema_name sub-key, but you're free to store additional configuration there.

Shared applications

Not yet.

The reason why django-appschema became hackish is that it tries to sync/migrate both isolated and shared applications in a single run. The app is shared if it has its tables in the public schema, hence they're accessible by every domain. That's because public schema is always checked after the object was not found in its "home" schema.

The support for shared application will be added to django-schemata as soon as it becomes clear it is required. And we strive to add the support in a more simple way: ALTER TABLE table SET SCHEMA schema looks very promising. We believe it's bearable for the admin to do some extra setup steps, when the code stays simple.


django-schemata requires the following modifications:

# We wrap around the PostgreSQL backend.
DATABASE_ENGINE = 'django_schemata.postgresql_backend'

# Schema switching upon web requests.

# We also offer some management commands.

# We need to assure South of the real db backends for all databases.
# Otherwise it dies in uncertainty.
# For Django 1.1 or below:
#SOUTH_DATABASE_ADAPTER = 'south.db.postgresql_psycopg2'
# For Django 1.2 or above:
    'default': 'south.db.postgresql_psycopg2',

# This maps all HTTP domains to all schemata we want to support.
# All of your supported customers need to be registered here. 
    'localhost': {
    	'schema_name': 'localhost',
    	'additional_data': ...
    '': {
    	'schema_name': 'firstclient',
    '': {
    	'schema_name': 'secondclient',

Management commands

./ manage_schemata

As soon as you add your first domain to settings.SCHEMATA_DOMAINS, you can run this. PostgreSQL database is inspected and yet-not-existing schemata are added. Current ones are not touched (command is safe to re-run).

Later more capabilities will be added here.

./ sync_schemata

This command runs the syncdb command for every registered database schema. You can sync all of your apps and domains in a single run.

The options given to sync_schemata are passed to every syncdb. So if you use South, you may find this handy:

./manage sync_schemata --migrate

./ migrate_schemata

This command runs the South's migrate command for every registered database schema.

The options given to migrate_schemata are passed to every migrate. Hence you may find

./ migrate_schemata --list

handy if you're curious or

./ migrate_schemata myapp 0001_initial --fake

in case you're just switching myapp application to use South migrations.

Bug report? Idea? Patch?

We're happy to incorporate your patches and ideas. Please either fork and send pull requests or just send the patch.

Discuss this project! Please report bugs.

Success stories are highly welcome.

Thank you.

Popular Django Projects
Popular Schema Projects
Popular Frameworks Categories

Get A Weekly Email With Trending Projects For These Categories
No Spam. Unsubscribe easily at any time.