DEV Community: Cecilia Wambui

makemigrations vs migrate in Django: What’s the Difference?

Cecilia Wambui — Fri, 24 Jul 2026 10:16:29 +0000

If you’ve ever edited your models.py, stared at your database, and wondered why nothing actually changed, don't worry, almost everyone trips over Django migrations when starting out. The confusion usually comes down to one thing: Django doesn't touch your database when you edit Python code. Changing a model is just drafting an idea. To actually update the database, you have to run two separate commands, in a specific order.
Here is what’s actually happening under the hood.

The Mental Model

Think of database changes in two stages: planning and executing.

models.py: Your blueprint. It defines what you want your data to look like in Python.
makemigrations: The planner. It inspects models.py, compares it against your past migrations, and generates a new instruction file (a migration script). It does not touch your database.
migrate: The executor. It reads those instruction files and actually runs the SQL to create or update your database tables.

A Quick Code Example

To see this in action, we'll use the Task model from our Django Beginner Tutorial on YouTube

from django.db import models
class Task(models.Model):
    title = models.CharField(max_length=200)
    description = models.TextField()
    completed = models.BooleanField(default=False)
    created_at = models.DateTimeField(auto_now_add=True)

    def __str__(self):
        return self.title

Editing this file is totally safe. You can add, tweak, or delete fields all day long, nothing breaks because Python hasn't talked to your database yet.

Step 1: makemigrations (Write the Plan)

When you're ready to lock in your schema changes, run:

python manage.py makemigrations

Django checks your app’s migrations/ folder, notices your new Task model, and creates a file named something like 0001_initial.py.
If you open that file, you’ll see Python code that describes the database operations needed to build that table.

Why doesn't Django just update the database automatically?

Keeping design separate from execution saves you from accidental disasters:

Sanity checks: You can look at the migration file before touching real data to ensure Django interpreted your changes correctly.
Version control: Migration files live in Git alongside your code, meaning your teammates get the exact same database setup when they pull down your branch.
Custom data fixes: If you need to transform or back up data before dropping a column, you can write custom logic inside the migration file first.

Step 2: migrate (Run the Plan)

Once the migration file looks good, run:

python manage.py migrate

Django checks a special hidden table in your database called django_migrations. It looks for any migration files in your project that haven't been run yet, executes the corresponding SQL (CREATE TABLE, ALTER TABLE, etc.), and checks them off the list.
Now your database schema matches your models.py.

The 2-Step Workflow in Action

Let’s add a deadline field to our task model:

# models.py
deadline = models.DateTimeField(null=True, blank=True)

Draft it: Run python manage.py makemigrations. Django creates 0002_add_deadline.py with an AddField instruction.
Apply it: Run python manage.py migrate. Django connects to PostgreSQL/SQLite and executes the SQL statement to add the column.

Common Beginner Confusions

"I ran makemigrations, but my admin panel didn't change!" You wrote the plan, but didn't execute it. Run python manage.py migrate.
"migrate says 'No migrations to apply', but I edited models.py!" You forgot to generate the plan. Run python manage.py makemigrations first.
"Why do I have so many migration files?" Think of them like Git commits for your database schema. They record your project's database history step-by-step so you can replicate or roll back changes anytime.
"Django asked me if I renamed a field, what do I do?" Pay attention to prompts like Did you rename task.due_date to task.deadline? [y/N]. If you hit "No", Django might delete the old column (and its data) and create a brand new empty one.

Practical Habits to Keep Your Database Safe

Commit your migrations: Always check your migrations/ folder into Git. Never .gitignore it.
Look before you leap: Skim auto-generated migration files before running migrate, especially in production.
Deploy together: Pull your latest code to the server, then run python manage.py migrate as part of your deployment build script.

Conclusion

Once you get used to this two-step workflow, database migrations stop feeling like a chore and start working like a safety net. You design your models in Python, verify the plan, and apply the changes when you’re ready, no unexpected schema drops and no lost data.

Never Deploy Django Without These 6 Things

Cecilia Wambui — Wed, 08 Jul 2026 06:28:12 +0000

Deploying a Django app feels great, until something breaks in production.
Everything may work locally, but once you deploy, you might run into missing styles, database errors, or an app that won’t start at all. That’s because Django’s default setup is built for development, not production.
Before you deploy, make sure these six essentials are in place. If you are using Render, you also need an account there first, because that is where your app and database will be created and managed.

Prefer Watching Instead?

If you’d rather see the full deployment process in action, I recorded a step-by-step walkthrough showing how to deploy a Django app to Render. You can watch it here: https://youtu.be/6x9tUZhbNaY?si=JeCYyFzpHipWlV9b

1. Gunicorn

Django’s built-in runserver command is only for development. It is great for testing and debugging, but it is not meant for real traffic or production use. Gunicorn is the server that actually runs your Django app in production.
Install it with:

pip install gunicorn

Then add it to your requirements.txt and start your app with a command like this during deployment on Render:

gunicorn project_name.wsgi

Django builds the app. Gunicorn serves it.

2. WhiteNoise

In development, Django can find your static files through STATICFILES_DIRS.
In production, that is not enough. WhiteNoise serves the collected static files from STATIC_ROOT, which is why it is so useful when deploying to Render.
A simple setup looks like this:

pip install whitenoise

Add the middleware:

MIDDLEWARE = [
    "django.middleware.security.SecurityMiddleware",
    "whitenoise.middleware.WhiteNoiseMiddleware",
]

Then define your static settings:

STATIC_URL = "static/"
STATICFILES_DIRS = [BASE_DIR / "static"]
STATIC_ROOT = BASE_DIR / "staticfiles"

If you are using a newer Django version, you should also configure STORAGES so Django knows how to handle static files properly:

STORAGES = {
    "default": {
        "BACKEND": "django.core.files.storage.FileSystemStorage",
    },
    "staticfiles": {
        "BACKEND": "whitenoise.storage.CompressedManifestStaticFilesStorage",
    },
}

This matters because STORAGES tells Django which storage backend to use.
The staticfiles setting makes WhiteNoise manage your static assets correctly in production, including compression and versioned file names.
So the flow is simple: STATICFILES_DIRS holds your source files, collectstatic gathers them into STATIC_ROOT, and WhiteNoise serves them from there in production.
Finally, collect the files:

python manage.py collectstatic

3. psycopg

SQLite is fine for development, but production usually needs PostgreSQL.
To let Django talk to PostgreSQL, you need psycopg.
Install it with:

pip install psycopg2-binary

Without it, Django cannot connect to your production database on Render or any other hosting platform using PostgreSQL.

4. dj-database-url

Most hosting platforms give you one database connection string.
Instead of breaking it apart manually, dj-database-url lets Django read it directly.
Install it with:

pip install dj-database-url

Then use it like this in your settings.py:

import dj_database_url

DATABASES = {
    "default": dj_database_url.config()
}

It keeps your database setup clean and simple, especially when moving between local development and a Render production database.

5. python-decouple

Never hardcode things like your SECRET_KEY, database password, or API keys in your project.
Those should live in environment variables instead.
python-decouple makes that easy:

pip install python-decouple

Then use it in your settings.py like this:

from decouple import config

SECRET_KEY = config("SECRET_KEY")
DEBUG = config("DEBUG", cast=bool)

This keeps sensitive data out of your code and makes deployment safer and easier to manage on Render.

6. requirements.txt

Your deployment platform starts with a fresh environment.
It only knows what to install if you give it a requirements.txt file.
Generate it with:

pip freeze > requirements.txt

If you forget to update it after adding packages, your deployment may fail because those packages won’t exist in production.

Common mistakes to avoid

Before deploying, double-check these:

DEBUG=True is turned off.
ALLOWED_HOSTS is set.
collectstatic has been run.
Migrations have been applied.
Secrets are not hardcoded.
requirements.txt is up to date.
You have an active Render account before trying to deploy.

Quick checklist

Gunicorn installed.
WhiteNoise configured.
PostgreSQL adapter installed.
Database URL handled properly.
Secrets stored safely.
requirements.txt updated.
Render account created and ready.

Conclusion

Deploying Django is not just about uploading code. It is about preparing your app for a production environment where security, performance, and reliability matter.
If you understand these six things, deployment becomes much smoother and much less stressful. Render makes the hosting part easier, but your Django project still needs to be properly prepared before deployment.

About DevNook

If you enjoy practical, beginner-friendly software development content, DevNook is built to help you become a better developer through real projects and clear explanations.
You can continue learning here:

YouTube for in-depth tutorials on Django, Python, React, JavaScript, APIs, deployment, Git, and more.
DevNook Website for step-by-step guides, articles, project walkthroughs, and learning resources.
GitHub for source code and project examples used throughout tutorials.

Thanks for reading, and happy coding!