Django 開発でよく発生するのが、マイグレーションとデータベースの不整合。
特に Docker でデプロイしながら開発していると、
- ローカルでマイグレーションをやり直した
- デプロイ先では古いマイグレーションが反映されたまま
InconsistentMigrationHistoryなどのエラーが出る
といった状況になりがちです。
結論として、判断基準の目安を示します。
| 判断基準 | おすすめ対応 |
|---|---|
| まだ開発フェーズ／テストデータのみ | DBを削除 |
| データに価値がある（本番やステージング） | 履歴を調整して整合性を取る |
| マイグレーションを大幅に作り直した | 開発段階なら「消す」、本番寄りなら「調整」 |
この記事では 「DBを消すべきケース」と「消さずに直すケース」 を整理し、それぞれの手順を端的にまとめます。
「まだ開発中」「テストデータしか入っていない」なら、マイグレーションを直すより DB を作り直したほうが早くて安全 です。
本番寄りの環境では、DB を消すと消えて困るデータがある場合が多いです。
この場合は、履歴を合わせていきます。
開発中とはいえ、docker volume rm は データベースを完全消去する破壊的操作 です。
以下の点を押さえておくと、安全に作業できます。
docker volume rm xxx_db-data は 元に戻せません。
- チーム開発なら、他メンバーが使っている DB を消さないよう注意
- 本番やステージングの volume 名と似ていると事故の元
- 削除前に必ず volume 一覧で 対象の volume 名を再確認
Bash
docker volume ls意図しない volume を消すミスが最も多いため、慎重に確認してください。
万が一間違ってDBを消しても復元できるよう、削除前にバックアップを取るのが理想です。
PostgreSQL の例
Bash
pg_dump -h localhost -U postgres -d mydb > backup.sqlSQLite の例
Bash
cp db.sqlite3 db-backup.sqlite3再現性のために「初期化スクリプト」を準備するのも有効
開発では DB を消す作業が何度も発生するので、次のようなスクリプトを用意しておくと良いです。
Bash
#!/usr/bin/env bash
set -e
docker compose down
docker volume rm project_db-data
docker compose up -d
docker compose exec app python manage.py migrate
docker compose exec app python manage.py loaddata initial_data.json環境構築が一瞬で終わります。
DB の volume を削除すると同時に、migrations/ ディレクトリを整理したいケースもあります。
その際の注意事項は次の通りです。
migrations/__init__.pyだけは必ず残す（これがないとアプリが migration パッケージとして認識されない）- チーム開発では、勝手に migration を消すと履歴が他メンバーとズレる
- Git で migration を削除する際は、全員で一斉に migration をリセットするタイミングを揃える
不要なマイグレーションの削除例
Bash
rm app_name/migrations/000*.py
touch app_name/migrations/__init__.pyその後、新しく作り直します。
Bash
python manage.py makemigrations
python manage.py migrateこれらの補足を押さえておくと、開発フェーズでも安全にマイグレーションの再構築が行えます。
Django × Docker の開発では、マイグレーション不整合はほぼ必ず起きます。
- 消してよいDBか？ 残すべきDBか？
- 「速く直す」か「丁寧に直す」か？
大事なのは、上記を状況で切り分けることが必要です。
コメント