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.