Django Appschema is born from the idea proposed by tidbids on SaaS with Django and PostgreSQL and SaaS with Django and PostgreSQL Schemas.

The main idea is to isolate customer's data in different schema. One customer = one schema. There are very good explanations on why schemas and what it could bring to your SaaS application on this thread on Hacker News.

On the running side, schema isolation is quite easy, set up a middleware that make dispatch, a signal and voilà (almost).

Django Appschema creates a table containing a public_name (could be FQDN or whatever your middleware decides) and a associated schema. This table should be shared by all schemas you'll create.

Now the complicated part. Performing syncdb on multiple schemas could be a bit difficult, specially if you want to share some apps and isolate some others (or both).

On your configuration file, you'll add APPSCHEMA_SHARED_APPS which is a list containing the apps you want to share. Basically, shared apps tables are created in public schema.

Appschema will alway be a shared app. If installed, South will be both shared and isolated.

Appschema comes with modified versions of syncdb and migrate that will perform required operations on schemas.

Another management command called createschema allows you to create a new schema and performs syncdb (and migrate if available) on the new created schema.

If you look at the code, you'll find a function called new_schema. You could be tempted to use it directly in your web app (for registration purpose). DON'T. NEVER. SERIOUSLY. In order to run properly, commands modify INSTALLED_APPS and the Django apps cache during execution. What is not an issue during a management command could become a nightmare in a runing Django process.

A first solution comes with schematemplate management command. This command creates a temporary schema, executes pg_dump on it and prints the result on standard output. It replaces the temporary schema name by a substitution pattern named %(schema_name). You can store this result for later use. Runing schematemplate command on each deployment is a good idea.

New: A function called new_schema_from_template (in appschema.models) performs the schema creation based on this template file.

Appschema provides a PostgreSQL (version 8.4 only) stored procedure called clone_schema(source, destination) (In contrib directory). It makes a copy of source schema on destination. Create a master schema and you could use it as a source for clone_schema. As this procedure is still a work in progress, you may prefer using the schematemplate way.

This highly experimental app works only for PostgreSQL.

You'll find a FqdnMiddleware which switchs schema based on the host name of the HTTP request. Feel free to make your own based on your needs.

If you find bugs (and I'm sure you will), please report them.

It wasn't test with multiple databases support and I'm not sure it works in such case.

Be careful with foreign keys. As you can make any foreign key you want in isolated app models referencing shared one, the opposite is not true.

Django appschema is released under the MIT license. See the LICENSE file for the complete license.