When I was preparing my Django portfolio for deployment, I had a decision to make:
Should I migrate the database from SQLite to PostgreSQL before going live?
From a technical-learning perspective, PostgreSQL was attractive.
It's a database I want to use more extensively in production Django applications, and moving to it would make the project architecture closer to what I expect from larger applications.
But I decided not to migrate.
At least, not yet.
Instead, I kept SQLite for the first version of my portfolio.
That decision taught me something important about software development:
Choosing the more advanced technology isn't always the same as making the right engineering decision for the current stage of a project.
What My Django Project Was Already Using
Django makes starting with SQLite extremely easy.
My database configuration followed Django's standard SQLite setup:
DATABASES = {
"default": {
"ENGINE": "django.db.backends.sqlite3",
"NAME": BASE_DIR / "db.sqlite3",
}
}
There is no separate database server to configure.
The database exists as a file:
project/
│
├── manage.py
├── db.sqlite3
├── portfolio_main/
├── blog/
├── contact/
└── ...
For local development, this was convenient.
My portfolio didn't begin as a high-traffic SaaS application.
It was a personal Django application containing portfolio pages, projects, blog content, contact functionality, and other supporting features.
SQLite allowed me to focus on building those features without introducing additional database infrastructure early in development.
Then Production Changed the Question
Once deployment entered the picture, the decision became more interesting.
SQLite and PostgreSQL aren't simply two different names for the same thing.
Their architecture is different.
With SQLite, the application works directly with a database file:
Django
│
↓
db.sqlite3
PostgreSQL introduces a separate database service:
Django Application
│
│ Database connection
↓
PostgreSQL Server
│
↓
Tables / Data
For a production application expected to grow, PostgreSQL offers an architecture much better suited to concurrent users, independent database infrastructure, and more demanding workloads.
So why didn't I immediately migrate?
Because the database wasn't the only production problem I was working on.
Deployment Already Had Enough Moving Parts
While getting my portfolio production-ready, I was already dealing with things that hadn't appeared the same way locally.
Static files needed production handling.
Environment configuration had to be correct.
I encountered filename case-sensitivity problems.
The contact email integration behaved differently in production.
The custom domain needed configuration.
The application had to work correctly with production settings.
Adding a database migration at the same time would have introduced another major variable.
The deployment could have become:
Django deployment
│
├── Static files
├── Environment variables
├── Production settings
├── Domain configuration
├── Email integration
│
└── SQLite → PostgreSQL migration
│
├── New database
├── Credentials
├── Connection settings
├── Migrations
└── Existing data
Every additional dependency creates another place where something can go wrong.
At that point, my priority was simpler:
Get the application deployed, stable, and working before introducing another architectural change.
The Difference Between "Best" and "Best Right Now"
This was probably the most useful part of the decision.
If someone asks:
Which database would you choose for a larger production Django application?
My answer wouldn't automatically be SQLite.
PostgreSQL would usually be much more appropriate for the kinds of backend applications I want to build.
But that wasn't exactly the question I needed to answer.
My question was:
Does migrating this portfolio to PostgreSQL right now provide enough value to justify adding another major change before deployment?
For the MVP, I decided the answer was no.
That distinction matters.
Software decisions exist within constraints.
Technical Decision
│
┌────────────────┼────────────────┐
│ │ │
Scale Complexity Timing
│ │ │
└────────────────┼────────────────┘
│
Current Need
The theoretically strongest technology isn't automatically the right technology at every stage.
Why SQLite Was Enough for the MVP
My portfolio doesn't currently need to process thousands of simultaneous database transactions.
Its main purpose is to present my development work and support content such as my technical blog.
For that stage, SQLite gave me several advantages.
It was already working.
It required almost no database administration.
It kept local development simple.
Most importantly, keeping it meant I could avoid changing a working part of the application while debugging unrelated production issues.
That's valuable.
Developers sometimes improve a system by adding something.
Other times, the better decision is knowing when not to change something yet.
But SQLite Has an Important Production Consideration
There is a major architectural difference I can't ignore.
SQLite stores its data in a file.
That means database persistence is tied to filesystem persistence.
Conceptually:
SQLite
Django
↓
db.sqlite3
↓
Server filesystem
Compare that with an externally hosted PostgreSQL database:
PostgreSQL
Django / Web Server
│
│ Network connection
↓
Database Service
↓
Persistent Data
Separating the application server from the database is an important advantage for production systems.
It also means I shouldn't interpret my MVP decision as:
"SQLite is all I'll ever need."
It's better described as:
"SQLite is sufficient for the current stage, while PostgreSQL remains the direction for a more production-oriented database architecture."
What a Future Migration Would Require
When I do move the project to PostgreSQL, I don't want the process to simply be:
# Change sqlite3 to postgresql
There is more to think about.
The application will need a database connection configuration.
Conceptually, the settings would move toward something like:
DATABASES = {
"default": {
"ENGINE": "django.db.backends.postgresql",
"NAME": config("DB_NAME"),
"USER": config("DB_USER"),
"PASSWORD": config("DB_PASSWORD"),
"HOST": config("DB_HOST"),
"PORT": config("DB_PORT", default="5432"),
}
}
Sensitive database credentials should come from environment configuration rather than being hardcoded.
Then I would need to verify:
PostgreSQL service
↓
Environment configuration
↓
Django connection
↓
Database migrations
↓
Existing application data
↓
Production testing
If existing data needs to be retained, that migration also becomes a data migration problem, not only a settings change.
That's something worth doing deliberately rather than squeezing it into an already complicated deployment.
Avoiding Resume-Driven Development
There's another lesson I took from this decision.
It would have been easy to add PostgreSQL simply so I could write:
Django + PostgreSQL
on the project's technology list.
But I don't want my portfolio to become a collection of technologies added only because they look good on a resume.
If I claim PostgreSQL as part of this project's architecture, I want to have actually integrated it, configured it, migrated the application, and dealt with the problems that come with it.
That experience is much more valuable than adding another logo to a project page.
The same principle applies to technologies such as Docker, Redis, Celery, AWS, or any other tool.
The question shouldn't be:
Can I add this technology?
It should be:
What problem does this technology solve in this application?
MVP Doesn't Mean Ignoring Architecture
Keeping SQLite doesn't mean architecture doesn't matter.
Actually, thinking about why I might eventually replace it is part of understanding the architecture.
My current decision can be represented like this:
CURRENT PORTFOLIO
│
Django Application
│
SQLite
│
Simple MVP architecture
FUTURE DIRECTION
│
Django Application
│
Database Connection
│
PostgreSQL
│
More production-oriented
database architecture
The important thing is that the transition should happen because the application's requirements justify it.
Not because PostgreSQL sounds more impressive.
What I Learned
This decision changed how I think about technology choices.
Earlier in my development journey, I often thought in terms of:
Basic technology
↓
Advanced technology
↓
Better application
Real projects are more complicated.
A better model is:
Requirements
+
Current scale
+
Deployment complexity
+
Future direction
+
Available time
↓
Engineering decision
Sometimes that decision means introducing a more powerful technology.
Sometimes it means keeping the simpler solution until there is a good reason to change it.
Shipping First, Improving Deliberately
I still want to migrate this project to PostgreSQL.
But when I do, I want the migration itself to be meaningful.
I want to understand the connection configuration, deployment implications, data migration process, persistence model, and problems that appear along the way.
And when that happens, it will probably become another article in this series.
For the first production version of my portfolio, however, I chose something simpler:
keep the working database, reduce the number of deployment variables, ship the application, and improve the architecture deliberately afterward.
Building my portfolio continues to teach me that software development isn't only about knowing more technologies.
It's also about knowing when a technology is actually needed.
I'm documenting the real technical decisions and production lessons behind building my Django portfolio instead of only showing the finished result.
You can explore the project at saddamshah.com.