What are Django migrations and how do makemigrations and migrate work?
Understand Django migrations — how makemigrations writes schema-change files and migrate applies them — with examples and common Django interview questions.
Expected Interview Answer
Django migrations are version-controlled instructions that keep your database schema in sync with your models; makemigrations detects model changes and writes migration files describing them, while migrate applies those files to the database to alter its schema.
When you change a model — add a field, rename a table, adjust a constraint — makemigrations compares the current models against the recorded migration state and generates a new migration file (a Python file of Operations like AddField or CreateModel). Running migrate then executes the unapplied operations as DDL against the database and records them in the django_migrations table so each is applied exactly once. Migrations are ordered by dependencies, can be run backwards, and are meant to be committed to version control so every environment reaches the same schema.
- Schema changes are versioned and reviewable like code
- Every environment converges on an identical, reproducible schema
- makemigrations autogenerates the DDL so you rarely write ALTER TABLE by hand
- Migrations can be reversed to roll a schema back
- The django_migrations table guarantees each migration runs only once
AI Mentor Explanation
Migrations are like a ground's over-by-over maintenance log. makemigrations is the groundsman inspecting the pitch and writing down exactly what must change — roll here, re-mark that crease — while migrate is the crew actually doing that work on the field. A ticked register (the django_migrations table) records what has already been done so no task is repeated, and the log lets you retrace or undo any change to the pitch.
Step-by-Step Explanation
Step 1
Change a model
Edit models.py — add, remove, or alter a field or model — creating a difference between your models and the current migration state.
Step 2
Run makemigrations
Django compares models to the last recorded state and writes a new migration file of Operations (AddField, CreateModel, etc.) into the app's migrations folder.
Step 3
Review the migration
Open the generated file to confirm the operations and dependencies are correct before applying them.
Step 4
Run migrate
Django executes unapplied operations as DDL against the database and records each in the django_migrations table so it is applied once.
Step 5
Commit and repeat
Commit the migration file to version control so every environment applies the same ordered changes; reverse with migrate app_label previous_migration if needed.
What Interviewer Expects
- Distinction between makemigrations (writes files) and migrate (applies to DB)
- Awareness that migrations are Python files of Operations, ordered by dependencies
- Knowledge of the django_migrations tracking table
- Understanding that migrations should be committed to version control
- That migrations can be reversed and inspected with sqlmigrate
Common Mistakes
- Thinking makemigrations changes the database — it only writes migration files
- Not committing migration files, causing environments to drift out of sync
- Editing the database schema manually and leaving migrations inconsistent
- Deleting or reordering applied migrations and breaking the dependency chain
Best Answer (HR Friendly)
“Django migrations keep the database structure in step with the code's data models. One command writes down what changed, and another command applies those changes to the database, so every developer and server ends up with exactly the same, reproducible schema.”
Code Example
# models.py — add a new field
class Book(models.Model):
title = models.CharField(max_length=200)
pages = models.PositiveIntegerField(default=0) # newly added
# Terminal: detect the change and write a migration file
# $ python manage.py makemigrations books
# -> books/migrations/0002_book_pages.py (AddField operation)
# Apply the migration to the database schema
# $ python manage.py migrate books
# Applying books.0002_book_pages... OK
# Preview the SQL a migration will run, without applying it
# $ python manage.py sqlmigrate books 0002Follow-up Questions
- How do you reverse or roll back an applied migration?
- What is a data migration and how does RunPython differ from schema operations?
- How does Django resolve migration dependencies across multiple apps?
- What does the --fake flag do and when would you use it?
- How would you squash a long chain of migrations?
MCQ Practice
1. What does 'python manage.py makemigrations' actually do?
makemigrations only generates migration files from model changes; it does not touch the database schema.
2. Which table records that a migration has already been applied?
Django records every applied migration in the django_migrations table so each runs exactly once.
3. Which command applies pending migrations to the database?
migrate executes the unapplied migration operations against the database as DDL.
Flash Cards
What does makemigrations do? — Detects model changes and writes migration files describing them — it does not alter the database.
What does migrate do? — Applies unapplied migration files to the database and records them in django_migrations.
How does Django know which migrations ran? — It records each applied migration in the django_migrations table so it runs only once.
How do you preview a migration's SQL? — Run python manage.py sqlmigrate app_label migration_name — it prints the SQL without applying it.