Django×SQLiteのDB運用完全ガイド ― runserver・マイグレーション・別窓操作の生成プロセスを理解する

Rails経験者がDjangoを触り始めると、最初に戸惑うのが「DBはいつ起動しているのか」「サーバー稼働中に別窓でDBを触って良いのか」「rails db:migrate:statusに相当するコマンドは何か」といった運用感覚の違いです。特にSQLiteは“単一ファイルDB”という特性を持ち、MySQLやPostgreSQLのような常駐サーバー型とは生成・接続・ロックの流れが大きく異なります。本記事では、Django開発サーバーとSQLiteがどのような生成過程で連携し、マイグレーションがどの段階でDB構造を更新し、別窓操作がどこまで安全なのかを体系的に解説します。実務開発で安心して運用するための「DBの動作原理が腹落ちする」永久保存版ガイドです。

runserverとSQLiteはどう連携してDBを生成・利用しているのか
- SQLiteは「起動型DB」ではなく「ファイル型DB」である
- runserver稼働中でも別窓でDBを開ける理由
マイグレーションはどの段階でDB構造を生成・更新するのか
- makemigrationsが「設計図」を生成する工程
- migrateとshowmigrationsが「反映状況」を可視化する
別窓からDBを操作する際の安全な実務フロー
- sqlite3 CLIによる直接確認フロー
- Django shellによるORM確認フロー
SQLite運用から本番DB移行までの発展的生成プロセス
- settings.pyでDBエンジンを差し替えるだけでよい理由
- 開発時に身につけるべきDB運用の最小ルール
参考リンク（ブログカード用）
〆最後に〆

runserverとSQLiteはどう連携してDBを生成・利用しているのか

Django開発サーバー（runserver）は「Webサーバー」と「ORM処理エンジン」を内包しており、リクエストが発生した瞬間にSQLiteファイルを開いて必要なクエリを実行します。SQLite自体は独立した常駐プロセスを持たず、単なるファイルとして存在します。つまり“DBが起動する”のではなく、“Djangoが必要な瞬間にファイルを開いて処理する”という生成・接続プロセスになっています。この仕組みを理解することで、別窓からDBを触ってよい範囲やロック発生条件が明確になります。

SQLiteは「起動型DB」ではなく「ファイル型DB」である

MySQLやPostgreSQLはバックグラウンドで常時稼働するDBサーバーが存在し、アプリケーションはそこへTCP接続します。一方SQLiteは単一ファイルを直接読み書きするライブラリ型DBです。Djangoはリクエスト処理時にsqlite3ライブラリを呼び出し、db.sqlite3ファイルを開き、SQLを実行し、処理が終わればファイルハンドルを解放します。この「必要な瞬間に開く」という生成過程が、SQLiteが“自動起動しているように見える”理由です。したがって、lsコマンドでdb.sqlite3ファイルが存在すればDBはすでに“利用可能状態”にあると理解できます。

runserver稼働中でも別窓でDBを開ける理由

SQLiteは複数プロセスからの「同時読み込み」を許可しています。runserverがSELECTを実行している間でも、別ターミナルでsqlite3 db.sqlite3を開いてテーブル確認やSELECTを行うのは完全に安全です。一方で書き込みが発生すると短時間の排他ロックが行われます。このとき別窓でINSERTやUPDATEを行うと「database is locked」エラーが出る場合があります。つまり安全領域は「読み込み専用操作」であり、書き込みを伴う操作はrunserver停止時に行う、という運用ルールが合理的です。

マイグレーションはどの段階でDB構造を生成・更新するのか

Djangoにおけるマイグレーションは「Pythonコードで定義したモデル構造」から「SQL構造を自動生成しDBへ反映する」工程を担います。この仕組みはRailsのActiveRecordマイグレーションと思想的に同じですが、実行フローや確認コマンドが異なります。makemigrations → migrate → showmigrations という3段階の生成過程を理解することで、DB構造がどのタイミングで作られ、どこまで反映済みかを常に把握できるようになります。

makemigrationsが「設計図」を生成する工程

python manage.py makemigrations は、models.pyの定義を解析し、「どのテーブルをどう作るか」をPythonコードのマイグレーションファイルとして生成します。この時点ではDBファイルはまだ変更されていません。つまり設計図だけが用意された段階です。Railsでいう「migrationファイル作成」と同等で、実データ構造は未反映のままです。複数人開発では、このマイグレーションファイル自体がGit管理対象となり、チーム共通のDB設計履歴になります。

migrateとshowmigrationsが「反映状況」を可視化する

python manage.py migrate を実行すると、生成済みマイグレーションファイルを順番に適用し、db.sqlite3内のテーブル構造を更新します。このときDjangoは内部のdjango_migrationsテーブルに「どこまで適用済みか」を記録します。そして python manage.py showmigrations を実行すると、[X]が適用済み、[ ]が未適用として一覧表示されます。これはRailsの db:migrate:status と全く同じ役割を果たし、DB構造の生成進行状況を常に把握できます。

別窓からDBを操作する際の安全な実務フロー

Django開発では、runserverを動かしながら別ターミナルでDB状態を確認したくなる場面が頻繁にあります。SQLiteのファイル型特性を踏まえれば、どの操作が安全で、どの操作が注意対象かが明確になります。ここでは「開発サーバー稼働」「sqlite3 CLI」「Django shell」という3つの操作窓が、どの順序でDBファイルへアクセスするかという生成プロセスを整理し、実務で事故らない運用手順を解説します。

sqlite3 CLIによる直接確認フロー

sqlite3 db.sqlite3 を別窓で開くと、Djangoとは独立してDBファイルを直接読むことができます。.tables でテーブル一覧、.schema テーブル名で構造確認が可能です。この操作は基本的に「読み取り中心」で行う限り安全です。実務では、runserver稼働中に「テーブルが生成されたか」「カラムが正しいか」を確認する用途で用いるのが最も合理的な使い方です。書き込みを行う必要がある場合はrunserver停止後に実施するのが安全です。

Django shellによるORM確認フロー

python manage.py shell はDjango ORM経由でDBにアクセスします。これはrunserverと同じコードパスでSQLiteファイルを開くため、「本番コードと同じ動作確認」が可能になります。例えば Model.objects.all() でデータ確認、Model._meta.fields でカラム一覧確認ができます。ORM経由で確認することで「SQLを書かずにDB構造とデータの両方を安全に確認できる」というDjango特有の強みを最大限に活かせます。

SQLite運用から本番DB移行までの発展的生成プロセス

開発段階ではSQLiteが便利ですが、本番運用ではPostgreSQLやMySQLへ移行するケースが一般的です。このときDjangoのマイグレーション設計がそのまま活き、DBエンジンを差し替えても同じ生成プロセスでテーブル構築が行われます。つまりSQLiteで確立した開発フローは、そのまま本番DBへスケール可能です。ここでは将来的な移行を見据えたDB運用設計の考え方を整理します。

settings.pyでDBエンジンを差し替えるだけでよい理由

DjangoはDATABASES設定により、SQLite・PostgreSQL・MySQLを抽象化しています。models.pyとマイグレーションファイルはDB非依存設計になっており、エンジンを切り替えても migrate を実行すれば新しいDBに同一構造が生成されます。この設計により「開発はSQLite」「本番はPostgreSQL」という自然な成長プロセスが成立します。