Multi-Tenant Applications with Separate Databases in Django

Based on the Django 5.1 documentation, Django does provide multi-database support, but it doesn't offer specific out-of-the-box functionality tailored for multi-tenant applications where each customer has their own database. However, Django's existing database routing capabilities can be leveraged to implement such a setup.

Current Multi-Database Support in Django

Django's multi-database support includes:

1. Automatic database routing: The default routing scheme ensures objects remain "sticky" to their original database, meaning an object retrieved from a specific database will be saved back to that same database.

2. Custom database routers: You can define and install your own database routers to implement more complex database allocation behaviors.

Limitations to Consider

When implementing a multi-tenant solution with separate databases, you should be aware of these limitations:

1. Cross-database relationships are not supported: Django doesn't support foreign key or many-to-many relationships that span multiple databases due to referential integrity concerns.

2. Contrib app dependencies: Several Django contrib apps have models that must be stored in the same database:

   • auth models (User, Group, Permission) must be in the same database as ContentType
   • admin models must be in the same database as auth
   • flatpages and redirects must be in the same database as sites

3. Automatic object creation: Some objects are automatically created after migration:

   • A default Site
   • ContentType for each model
   • Permission for each model

   For multi-tenant setups, it's recommended to use a database router that synchronizes these models to only one database to avoid data corruption.

Implementation Approach

While not built-in specifically for multi-tenancy, you could implement a multi-tenant solution using Django's database routing by:

1. Creating a custom database router that directs queries to the appropriate tenant database based on the current tenant context
2. Managing database connections dynamically based on tenant identification
3. Ensuring shared models (like auth) are properly handled across tenants

This would require careful consideration of how to maintain tenant context throughout the request lifecycle and how to handle the limitations mentioned above.

The lack of built-in multi-tenant functionality with separate databases is a design choice that allows Django to remain flexible while providing the building blocks for custom implementations.