データベースマイグレーションは、データベースの構造や中身を新しい状態へ移行する作業です。アプリケーション開発では、テーブル追加、カラム追加、型変更、制約変更、既存データの変換などを、履歴として管理しながら反映する意味で使われます。
まず押さえたいポイント
- スキーマ変更とデータ移行の両方を含むことがある
- コードのデプロイとは違い、データや構造そのものを変える
- 本番ではロック、実行時間、互換性、戻しにくさが問題になりやすい
- 大きな変更では段階移行が必要になる
- 便利な migration ツールがあっても、本番で安全とは限らない
どんな場面で使うか
新しいカラムを追加する、不要な列を整理する、テーブル構造を見直す、既存データを新しい形式に変換する、といった場面で使います。Laravel や Prisma のようなツールでは、変更履歴をコードとして持ち、環境ごとに同じ順序で適用しやすくします。
ただし、本番環境では、単に migrate を実行する だけでは不十分です。大きなテーブルに対する変更、NOT NULL 制約の追加、型変更、大量更新などは、短時間でもロックや待ちを生み、APIや画面の遅延につながることがあります。
本番で注意が必要な理由
本番ではユーザー操作、外部API、バッチ、管理画面などが同時に動いています。そのため、開発環境で一瞬で終わる変更でも、本番では負荷や競合が出ることがあります。また、旧版アプリと新版アプリが同時に動く時間帯があると、先に列を消す、必須制約を強くする、といった変更で互換性が崩れることがあります。
こうした理由から、データベースマイグレーションはアプリの変更と順序を合わせ、必要に応じて段階移行することが大切です。詳しくは データベースマイグレーションとは？本番反映で注意する理由 で整理しています。
注意点
ロールバック用の処理が書かれていても、実データが完全に元通りになるとは限りません。削除や値変換を含む変更では、業務上は戻しにくいことがあります。そうした場面では、ロールフォワードで前へ進める前提を考えることもあります。
また、大きな変更では、一度に置き換えるより、新旧両対応期間を作る方が安全です。新カラム追加、データコピー、読み取り先切り替え、旧カラム削除のように段階を分ける考え方は、実務でよく使われます。