Migrations in Django

Migrations are Python files that describe incremental changes to your database schema — adding a table, adding a column, altering a field's type — generated by running python manage.py makemigrations after changing models.py. Each migration file lists dependencies on prior migrations, forming a directed graph that Django's migration executor walks in order when you run python manage.py migrate. Migrations are database-agnostic: the same migration file can generate PostgreSQL, MySQL, or SQLite DDL depending on your configured backend.

makemigrations only writes migration files to disk based on differences it detects between your models and the last known migration state — it does not touch the database. migrate is the command that actually applies (or reverses) those files against a real database, and Django tracks which migrations have run per app in the django_migrations table. Running python manage.py sqlmigrate app_name 0003 prints the raw SQL a migration will execute without running it, which is useful for reviewing risky schema changes like column drops before they hit production.

Beyond schema changes, migrations can also transform data using RunPython, letting you write a forward function (and optionally a reverse function) that operates on historical model state accessed via apps.get_model() rather than importing the model directly — this matters because the model as it exists today may have fields that didn't exist when an old migration ran. A common safe pattern for adding a required field to a table with existing rows is a three-step migration: first add the field as nullable, then run a data migration to backfill values, then a final migration to make the field non-nullable.