Will It Vibe?SQLite database engine in a production-looking settings file
Part of Architecture & Best Practices, which counts for 15% of the overall score. When this check fires it deducts 4 points from that category, once per scan, no matter how many places it turns up.
What it detects
DATABASES declares django.db.backends.sqlite3 in a settings file that does not look like a dev/local/test variant. SQLite works fine for local development but does not handle concurrent writers well, which is a common source of 'database is locked' errors under real production traffic. This is a best-practice heuristic: some small, low-concurrency apps run SQLite in production on purpose.
Why it matters
SQLite handles concurrent writers by serializing them with a file lock, so under real production traffic with more than a handful of simultaneous writes, requests start failing with 'database is locked' errors that never showed up in development against a handful of test rows. It also does not support several patterns production Django apps rely on (proper ALTER TABLE for some migrations, robust concurrent access across multiple app server processes). This is a best-practice heuristic: a small, genuinely low-concurrency app can run SQLite in production on purpose.
How to fix it
Switch the production DATABASES entry to PostgreSQL (or MySQL/MariaDB) with the appropriate ENGINE (django.db.backends.postgresql) and connection settings sourced from the environment (DATABASE_URL via dj-database-url, or individual HOST/PORT/NAME/USER/PASSWORD variables). Keep SQLite for local development and CI if that is convenient; just do not let it reach the production settings.
The paid report includes a ready-to-paste prompt for your AI coding agent for every check it finds, pointed at the exact findings from your scan. See pricing
Does your repo trip this check?
Paste a GitHub URL or drop a project folder. Scans run in your browser and take seconds.
Scan your repo