DEV Community: Michael Nyawade

I Kept Recreating My Django Superuser Every Time I Switched Computers — Until I Finally Understood What Was Happening

Michael Nyawade — Tue, 02 Jun 2026 12:24:36 +0000

I’ve been building a Django project called SmartDuka, a smart shop management system for small retailers and shop owners. It handles inventory tracking, low stock alerts, dead stock detection, sales tracking, credit sales, and daily business insights.

This is also my first serious Django project.

And for a while, every time I switched from my home laptop to my work laptop, I went through the exact same process:

git clone
python -m venv venv
pip install -r requirements.txt
python manage.py migrate
python manage.py createsuperuser

Then I would open the admin panel and start entering products, customers, and sample sales all over again.

Every. Single. Time.

At first, I thought this was just part of working with Django. But eventually I realized I wasn’t actually understanding the relationship between:

my code
migrations
and the database itself

This article is basically the explanation I wish someone had given me earlier.

The Mistake I Wasn’t Really Making

To be fair, I was doing one important thing correctly:

db.sqlite3

was inside my .gitignore.

For a good reason SQLite databases are local files and usually shouldn’t be committed to Git.

So technically my workflow looked “correct.”

The problem was this:

I assumed migrations would somehow preserve my data across machines.

They don’t.

What Django Migrations Actually Do

This part finally clicked for me after some frustration.

When you run:

python manage.py migrate

Django recreates the database structure, not the actual records inside it.

So migrations restore things like:

tables
columns
relationships
constraints

But they do not restore:

superusers
products
inventory
sales records
customers
suppliers

That data lives inside the database itself.

And in SQLite, that database is literally one file:

db.sqlite3

Once I understood that, everything made sense.

Why I Had to Keep Recreating My Superuser

Because every new machine was getting:

fresh empty database

After migrations, Django had the tables it needed, but there were no actual records inside them yet.

So naturally:

no users existed
no inventory existed
no sales existed

I wasn’t losing my code.

I was losing my database state.

The Different Solutions I Considered

Once I understood the problem properly, I realized there are several ways developers approach this.

1. Recreate Everything Every Time

This was my original workflow.

It technically works, but only for tiny projects.

Once your app starts accumulating meaningful data, this becomes painful very quickly.

2. Commit `db.sqlite3` to Git

I considered this briefly.

It solves the syncing issue, but introduces other problems:

binary file conflicts
messy Git history
merge problems
potential security risks

For a real project, this didn’t feel right.

3. Use Fixtures

Django supports:

python manage.py dumpdata
python manage.py loaddata

which export and import data as JSON fixtures.

This is actually pretty useful for:

demo data
seed data
lookup tables

But for constantly changing business data like inventory and sales, it felt awkward as the main solution.

4. Copy `db.sqlite3` Between Machines

This ended up being the most practical short-term solution for me.

Instead of recreating everything, I simply keep the latest SQLite database and transfer it between machines manually.

That preserves:

my superuser
inventory records
customers
sales history
everything else

The workflow now looks more like this:

git pull
pip install -r requirements.txt
# copy latest db.sqlite3
python manage.py migrate
python manage.py runserver

Much better.

The Important Detail About Migrations

One thing I learned here:

The correct order is:

copy db.sqlite3
then run migrations

Not the other way around.

Why?

Because migrations should update your existing database schema if new model changes were added.

For example, if yesterday my Product model had:

name = models.CharField(max_length=100)

and today I added:

price = models.DecimalField(...)

then running:

python manage.py migrate

updates the copied database safely.

That’s exactly what migrations are designed for.

The Bigger Realization

At some point, I realized SmartDuka started behaving like a real system.

And once that happens, things like:

persistence
synchronization
database strategy
backups
scalability

suddenly become important.

That transition caught me by surprise a little.

What I’m Planning Next

Right now I’m still using SQLite during development because it’s simple and fast.

But I can already see that eventually I’ll need to move toward PostgreSQL, especially because SmartDuka deals with:

transactions
inventory
analytics
credit management
reporting

At that point, having a shared database instead of manually copying SQLite files will make much more sense.

But honestly, understanding why I was recreating my superuser every time was already a huge learning moment.

Final Thoughts

One thing I’m learning while building real projects is that software development isn’t only about writing features.

Sometimes the biggest lessons come from workflow problems.

This was one of them for me.

If you’re new to Django and you’ve ever wondered:

“Why do I keep losing my data even after running migrations?”

hopefully this article saves you a few hours of confusion.

Why Adding a Unique SKU Field Broke My Django Migration

Michael Nyawade — Sun, 10 May 2026 08:05:18 +0000

In building projects using Django, one thing that I have realized about database migrations is that things may appear simple until the moment one alters an existing model.

For example, in developing an inventory management app for my project recently, I experienced a migration problem, which, although small, helped me understand how migrations work within Django and in particular, when adding unique constraints to existing databases.

I would like to document this problem since someone else may have experienced the same thing.

The Initial Inventory Model

At the beginning, my Product model was simple.

from django.db import models


class Product(models.Model):
    name = models.CharField(max_length=100)
    buying_price = models.DecimalField(max_digits=10, decimal_places=2)
    selling_price = models.DecimalField(max_digits=10, decimal_places=2)
    stock_quantity = models.PositiveIntegerField(default=0)
    low_stock_threshold = models.PositiveIntegerField(default=5)
    created_at = models.DateTimeField(auto_now_add=True)

    def __str__(self):
        return self.name

After creating the model, I generated and applied migrations:

python manage.py makemigrations
python manage.py migrate

I also registered the model in admin.py:

from django.contrib import admin
from .models import Product


admin.site.register(Product)

Everything worked perfectly.

I created a superuser, logged into the Django admin panel, tested the model, and there were no issues.

Updating the Inventory App

As the project evolved, I realized the inventory system needed product categories and SKU support.

So I updated models.py.

from django.db import models


class Category(models.Model):
    name = models.CharField(max_length=100, unique=True)

    class Meta:
        verbose_name_plural = "Categories"

    def __str__(self):
        return self.name


class Product(models.Model):
    category = models.ForeignKey(
        Category,
        on_delete=models.CASCADE,
        related_name='products'
    )

    name = models.CharField(max_length=100)
    sku = models.CharField(max_length=50, unique=True)

    buying_price = models.DecimalField(max_digits=10, decimal_places=2)
    selling_price = models.DecimalField(max_digits=10, decimal_places=2)

    stock_quantity = models.PositiveIntegerField(default=0)
    low_stock_threshold = models.PositiveIntegerField(default=5)

    created_at = models.DateTimeField(auto_now_add=True)

    def profit_per_item(self):
        return self.selling_price - self.buying_price

    def is_low_stock(self):
        return self.stock_quantity <= self.low_stock_threshold

    def __str__(self):
        return self.name

I also updated admin.py:

from django.contrib import admin
from .models import Category, Product


admin.site.register(Category)
admin.site.register(Product)

Then I created new migrations.

At this point, I expected everything to work normally.

Instead, Django threw a migration error.

The Error I Encountered

When I ran:

python manage.py migrate

I got this:

django.db.utils.IntegrityError:
UNIQUE constraint failed: new__inventory_product.sku

At first, I was confused.

The sku field looked correct:

sku = models.CharField(max_length=50, unique=True)

So why was the migration failing?

What Was Actually Happening

After looking into it more carefully, I realized the issue was related to existing database records.

Before adding the sku field, the Product table already existed in the database.

When Django attempted to apply the migration, SQLite internally tried to:

Create a new version of the table
Copy the old data into the new table
Apply the new constraints

The problem was that the new sku field had unique=True.

Existing records in the database didn’t have SKU values yet.

As SQLite tried moving data into the new table structure, duplicate empty values conflicted with the unique constraint.

That’s why the migration failed.

How I Fixed It

Since I was still in the development stage of the project, I decided to reset the database completely.

Here’s what I did:

1. Stopped the Development Server

CTRL + C

2. Deleted the SQLite Database

db.sqlite3

3. Deleted Old Migration Files

I deleted the migration files inside the app’s migrations folder, except:

__init__.py

4. Recreated Migrations

python manage.py makemigrations

5. Applied Migrations Again

python manage.py migrate

6. Recreated the Superuser

python manage.py createsuperuser

After that, everything worked correctly.

What I Learned

This experience taught me an important lesson:

Adding unique fields to existing Django models can break migrations if the database already contains records.

Even though the code itself may look correct, the migration process also depends on the current database state.

I also learned that:

Resetting the database is acceptable during early development
It is not a good solution for production systems
Database schema changes should be planned carefully
Unique constraints require special attention when existing data is involved

A Better Production Approach

If this were a production project, deleting the database would obviously be a bad idea.

A safer approach would be:

Add the field without unique=True
Populate existing rows with unique values
Then apply the unique constraint in a later migration

That prevents conflicts with existing records.

Final Thoughts

This wasn’t the biggest bug I’ve encountered in Django, but it was one of those moments that helped me understand migrations better.

Sometimes small errors teach the most useful lessons.

If you’re learning Django and run into migration issues after modifying models, don’t panic immediately. In many cases, the problem is related to how existing database records interact with the new schema changes.

Hopefully this saves someone else a few hours of confusion.

DEV Community: Michael Nyawade

I Kept Recreating My Django Superuser Every Time I Switched Computers — Until I Finally Understood What Was Happening

The Mistake I Wasn’t Really Making

What Django Migrations Actually Do

Why I Had to Keep Recreating My Superuser

The Different Solutions I Considered

1. Recreate Everything Every Time

2. Commit db.sqlite3 to Git

3. Use Fixtures

4. Copy db.sqlite3 Between Machines

The Important Detail About Migrations

The Bigger Realization

What I’m Planning Next

Final Thoughts

Why Adding a Unique SKU Field Broke My Django Migration

The Initial Inventory Model

Updating the Inventory App

The Error I Encountered

What Was Actually Happening

How I Fixed It

1. Stopped the Development Server

2. Deleted the SQLite Database

3. Deleted Old Migration Files

4. Recreated Migrations

5. Applied Migrations Again

6. Recreated the Superuser

What I Learned

A Better Production Approach

Final Thoughts

2. Commit `db.sqlite3` to Git

4. Copy `db.sqlite3` Between Machines