Version 1 of this Django Portfolio worked. It ran on SQLite, which is Django's default database — no configuration needed, no server to manage, just a file on disk. For a solo project in development, that is perfectly fine.

Version 2 is a rebuild. With it came the decision to use PostgreSQL in production. SQLite is not designed for concurrent access or for running on hosted platforms where the filesystem may be ephemeral. A real deployment needs a real database.

Keeping SQLite in development

I did not switch to PostgreSQL everywhere — only in production. In development, SQLite is still the right tool: it requires no setup, starts instantly, and is easy to reset. The switch in settings.py is straightforward:

if DEBUG:
    DATABASES = {
        "default": {
            "ENGINE": "django.db.backends.sqlite3",
            "NAME": BASE_DIR / "django_project.sqlite3",
        }
    }
else:
    DATABASES = {
        "default": {
            "ENGINE": "django.db.backends.postgresql",
            ...
        }
    }

This pattern — SQLite locally, PostgreSQL in production — is common in Django projects and keeps the development environment lightweight without sacrificing production correctness.

What this opened up

With the database decision made, the next question was media files. In version 1, project images lived in core/media/ alongside the code. That was fine when everything ran locally. In version 2, deployed to a hosted platform with an ephemeral filesystem, it was no longer an option. That question — where do the images go? — is what the next article is about.