Managing Django migrations with multiple isolated databases (one per app)

Using Django Using the ORM
1

Hi everyone,
straight to the point.

I’ve worked with Django and PostgreSQL before, using a single database for all project apps, as is commonly done.

Currently, I’m facing a different scenario: I need each app to have its own isolated database, using MariaDB, with its own user and password. This is because we’re migrating from a legacy PHP system that is already structured this way, and part of the goal is to preserve existing backup and operational processes. So using a single schema/database for all Django apps is not a viable option for us.

I’ve reviewed the documentation and understand this isn’t a common use case in Django, although it is technically possible using database routers. However, the main problem I’ve encountered relates to the django_migrations table.

Current operational context

To handle this scenario, we’ve made the following architectural decisions:

  • All migration tracking and control is centralized in the main database (CORE_P_DJANGO, the default alias), which also holds Django’s internal tables (auth, admin, etc.).
  • Business models for each app are migrated into their respective databases (CORE_P_UGO, CORE_P_KERNEL, etc.).
  • We allow Django to automatically create a django_migrations table in each app database, but we ignore its contents for migration tracking purposes.
  • We use a custom command, manage.py migrate_db, which applies migrations to the appropriate database but registers them only in CORE_P_DJANGO.

Important notes

  • We never rely on the django_migrations table present in the app-specific databases.
  • We never manually modify those tables.
  • All migration tracking is centralized in the django_migrations table of CORE_P_DJANGO.

I’m wondering if this is a reasonable approach. I’ve also considered running a separate Django project for each app using Apache + mod_wsgi, but I’m concerned about the performance and maintainability impact. Right now we have a few apps, but once the migration is complete there will be 40+ apps.

So, here are my questions for you:

  • Does this approach make sense?
  • Is there a better practice for handling multiple isolated databases per app in Django?
  • Is there anything in Django’s roadmap regarding better support for this kind of setup?
  • Am I overcomplicating things, and maybe missing a simpler solution?

Thanks in advance for any insights or shared experiences!

2

<opinion>
Not to me.

Django already handles this issue by using routers and the --database parameter on migrate. I’m not sure I understand why you would consider replacing this existing structure to be preferable.

Using the routers to define which apps/models are applied to your different databases provides a huge degree of flexibility that I would hesitate to give up.
</opinion>

I’m not sure I understand what you’re referring to as not being “a common use case”. Working with multiple databases is something we do quite regularly. (Although, in the majority of cases the additional databases are “read-only” reference tables.)

I think the decision here would depend a lot upon how much overlap there is between these apps. If there isn’t a lot of interaction or shared data between them (other than using urls to switch from one to the other), this would be my preferred approach.
(Note: If you decided to separate these apps, I would recommend using nginx/uwsgi or nginx/gunicorn instead of Apache/mod_wsgi to allow for independent management of those different processes.)

2 Likes
3

Hi Ken!

Thank you very much for your reply.
After posting the message (my first time here), I was left wondering about the --database parameter after reading some similar cases on the forum.

I think I overcomplicated things. I’m going to try it as you recommend. I’ll leave an update here later on how it went.

Thank you very much for your reply! I really appreciate it. :smiley:

2 Likes