database-migrator

データベース移行ツール

データベースプロバイダー間で、スキーマ、データ、ロジックを移行します。これはプロバイダー間の移行エンジンであり、スキーマ設計ツールではありません。データ型の非互換性、プロバイダー固有の SQL 方言、外部キーの順序、シーケンスと自動採番の変換、トリガーの書き換え、ストアドプロシージャの変換に対応します。行数とチェックサムで検証し、監査可能な migration-plan.md を生成します。

目次

• references/schema-discovery.md -- リレーショナルデータベース、MongoDB、Supabase、PlanetScale のソースを対象とした抽出クエリ。
• references/type-mapping.md -- データ型マップ（PG/MySQL/Mongo）と SQL 関数の変換。
• references/script-generation.md -- DDL、シーケンス、トリガー、プロシージャ、ビューの変換。
• references/data-migration.md -- プロバイダー別のエクスポート、変換、インポートコマンド。
• references/validation.md -- 行数、チェックサム、外部キーの整合性、インデックス、スポットチェックのクエリ。
• references/rollback-and-downtime.md -- ロールバックスクリプト、バックアップと復元、ダウンタイムの見積もり。
• references/migration-plan-template.md -- migration-plan.md の完全な出力テンプレート。
• references/edge-cases.md -- 大規模テーブル、情報損失を伴うマッピング、ドキュメントのフラット化、複数スキーマ、品質チェックリスト。

対応する移行経路と複雑さ

対応する移行元と移行先の組み合わせ：PostgreSQL、MySQL、Supabase（Postgres）、PlanetScale（MySQL）、MongoDB。方向は問いません。

• 低：同じ基盤エンジン間（例：Postgres から Supabase）。主に接続と権限の変更が必要です。
• 中：同じパラダイムで方言が異なる場合（例：Postgres から MySQL）。データ型のマッピングと方言の変換が必要です。
• 中～高：方言が異なり、プロバイダーの制約もある場合（例：PlanetScale ではデータベースレベルの外部キーを使用できません）。
• 高：パラダイムの転換（例：リレーショナルデータベースからドキュメントデータベース）。単なる変換ではなく、スキーマの再設計が必要です。

使用する場面

• 本番データベースを別のプロバイダーに移行する場合。
• セルフホスト型サービスとマネージドサービスの間で移行する場合。
• マルチクラウドや災害復旧のために、プロバイダー間でスキーマを複製する場合。
• 複数のデータベースを単一のプロバイダーに統合する場合。
• リレーショナルデータベースと MongoDB の間で、完全なデータモデルを変換する場合。
• 本番環境で実行する前に、検証済みで監査可能な移行計画を作成する場合。

使用しない場面

• 新しいスキーマをゼロから設計する場合（database-schema-designer を使用してください）。
• フレームワーク間でアプリケーションコードを移行する場合（full-codebase-migrator を使用してください）。
• 数個の列を変更する、またはテーブルを1つ追加する場合（ALTER 文を直接記述してください）。
• リアルタイムレプリケーションや CDC の場合。このスキルが生成するのは特定時点のスクリプトであり、ストリーミングパイプラインではありません。

ワークフロー

このスキルが呼び出されたら、次の手順に正確に従ってください。

1. 移行パラメーターを収集します。移行元プロバイダーとバージョン、移行先プロバイダーとバージョン、接続方法（ライブまたはダンプファイル）、スキーマの範囲（対象のスキーマ／テーブル）、データ移行（スキーマのみ、またはスキーマとデータ、全件または一部）、許容できるダウンタイム、データ量、アプリケーションの依存関係、出力先（デフォルトは現在のディレクトリ）を確認します。ユーザーがすでにこれらを提示している場合は、質問を省略して次に進みます。

2. 移行元のスキーマを調査します。テーブル、カラム、型、デフォルト値、制約、インデックス、外部キー、トリガー、プロシージャ、関数、ビュー、シーケンス、列挙型、行数を抽出します。MongoDB の場合は、コレクションをスキャンしてスキーマを推定します。Supabase の場合は、RLS ポリシー、拡張機能、パブリケーションも抽出します。references/schema-discovery.md を参照してください。

3. データ型をマッピングします。移行元のすべての型を、移行先で最適な型に変換し、情報の損失や精度が変わる変換にはフラグを付けます。プロバイダー固有の SQL 関数も変換します。references/type-mapping.md を参照してください。

4. スキーマスクリプトを生成します。トポロジカルソートでテーブルの作成順序を決定します（循環する外部キーは後回しにします）。DDL を生成し、シーケンス／自動インクリメントを変換し、トリガーとストアドプロシージャを書き換え、ビューを変換します。references/script-generation.md を参照してください。

5. データ移行スクリプトを生成します。移行元および移行先のプロバイダー向けに、エクスポート、変換、インポートのコマンドを作成します。references/data-migration.md を参照してください。

6. 検証計画を生成します。移行元と移行先の行数、チェックサム、外部キーの整合性、インデックス、トリガー／プロシージャ、およびサンプルデータのスポットチェック用クエリを作成します。references/validation.md を参照してください。

7. ロールバック計画とダウンタイムの見積もりを作成します。逆順の DROP スクリプト、バックアップ／復元コマンド、アプリケーションのロールバック手順、削減策を含む段階的なダウンタイムの見積もりを作成します。references/rollback-and-downtime.md を参照してください。

8. migration-plan.md を生成します。エグゼクティブサマリー、範囲、スキーマのインベントリ、型マッピング、非互換性、スクリプト、検証、ロールバック、ダウンタイム、リスク評価、チェックリスト、手順ごとの実行ガイド、必要なアプリケーションの変更をまとめます。references/migration-plan-template.md のテンプレートを使用してください。

9. エッジケースに対応します。極めて大きなテーブル、情報の損失を伴うマッピング、MongoDB ドキュメントのフラット化、PlanetScale の外部キー回避策、Supabase 固有の事項、複数スキーマの移行を考慮します。品質チェックリストに照らして計画を検証してください。references/edge-cases.md を参照してください。