判断：環境変数をPostgreSQL向けに変えるだけでは移行完了になりません。先にバックアップを取り、残すデータを決め、現行バージョンの公式手順で移行・検証してください。
適するケース：SQLiteで長期運用中の個人開発者、ワークフローや認証情報を保ったまま移行したい小規模チーム、n8n 2.xへの更新とデータベース移行を分けて進めたい担当者向けです。
個人運用で決める移行範囲
SQLiteを使っているからといって、すぐにPostgreSQLへ切り替える必要はありません。試用中でデータ量や同時利用の課題がまだなく、旧データも必要であれば、移行を急がず、まず現状のバックアップと復元確認を行う選択肢があります。
一方、長期運用に入り、複数のサービスからデータベースを扱う、または運用基盤をPostgreSQLにそろえる必要があるなら、移行計画を作ります。n8nはSQLiteを既定のデータベースとして案内し、PostgreSQLの設定も提供していますが、接続先の変更だけでSQLite内のレコードが複製されるわけではありません。構成項目は公式データベース設定で確認してください。
SQLiteのまま続けるか、移行するかはどう判断しますか。
旧データを残す必要がなく、これから必要なワークフローだけを用意するなら、新しいPostgreSQL環境を作り、必要な業務データを移す方法を検討できます。既存の認証情報、ユーザー設定、共有関係、実行履歴が必要なら、まず対象データごとに移行手段と復元方法を確認します。
移行先を作る前に、バックアップの保存場所と復元担当も決めます。バックアップを取っただけで復元可能と判断せず、複製環境で読み戻せることを確認してください。運用データの保管場所や取り扱いを整理する場合は、データの取り扱いに関する案内も確認できます。
単独の本番運用では必要データを分類
ワークフローと認証情報は、移行対象として分けて扱います。n8nのCLIではワークフローと認証情報のインポート、エクスポートが案内されていますが、インポート時にIDが既存データと重なると、意図しない上書きにつながる場合があります。実行するコマンドとオプションは現行のCLI資料で確認し、本番データへ直接試さず、複製環境で先に検証してください。
認証情報については、暗号化に使うキーを現行環境と移行先で照合します。キーを引き継がずに移すと、移行後に保存済みの認証情報を利用できないおそれがあります。キーの保管先、権限、復元手順を記録し、平文の認証情報を作業ログや共有ファイルへ残さないようにします。
| 運用状況 | 移行の考え方 | 切替前に確認する点 |
|---|---|---|
| 個人の試用環境 | 旧データが不要なら、新規環境へ必要なワークフローを移す方法を検討 | 必要な認証情報と設定を選別し、旧DBを保管 |
| 長期運用中の個人環境 | ワークフローと認証情報を別々に移行・検証 | CLIのID上書きリスク、暗号化キー、復元可能性 |
| チーム運用 | データのインポートだけで完了とせず、ユーザーや共有関係を検証 | 各担当者の見える範囲、ワークフローの所有・共有状態 |
| 実行履歴を保持する環境 | 履歴を独立した移行対象として扱い、対応する手段を先に確認 | 完全性、参照可能性、復元方法、移行後の保存領域 |
チーム運用ではユーザーと共有関係を確認
ワークフローと認証情報を移せても、チームで使っていた状態まで再現できるとは限りません。ユーザー、プロジェクト、共有範囲、ワークフローの関連付けは、チーム運用に必要な別の確認対象です。公式のワークフロー共有に関する説明を読み、対象バージョンと利用形態で何が共有されるか確認してください。
切替前に、担当者ごとに閲覧できるワークフローと利用する認証情報を記録します。複製環境へ移行した後、同じ担当者でログインし、移行前後で見える範囲や利用可否を照合します。管理者の画面だけで確認を終えると、一般ユーザーの権限不足や、共有されていない認証情報を見落とすことがあります。
実行履歴を残す場合は別経路として検証
実行履歴は、ワークフローや認証情報と同じ手順で移せると決めつけないでください。履歴を業務上保持する必要がある場合、対象バージョンの公式資料で対応する移行方法を確認し、履歴が欠落・破損せず参照できることをテストします。公式の実行データ保持に関する説明は、保存対象や保持方針を検討する際の確認先です。
移行時に実行履歴を残す必要がありますか。
障害調査や業務監査で過去の実行内容を参照する要件があるなら、保管期間と復旧後の参照要件を決めてから移行方法を選びます。履歴を保持しない運用にできる場合は、新しいデータベースへ必要な業務データだけを移す選択肢がありますが、既存環境を削除する前に関係者の合意とバックアップの復元確認が必要です。
履歴を移すためにコミュニティスクリプトを使う場合は、公式手順とは分けて扱います。移行前後の記録件数だけでなく、個別記録の内容、関連ワークフローへの参照、復元可否、必要な保存領域を試験環境で確認してください。n8nのバイナリデータ保存に関する資料も参照し、実行履歴と関連ファイルを同一のデータとして扱わないようにします。
n8n 2.xではバージョン更新とDB移行を分離
n8n 2.xへの更新を同時に行う場合、データベース移行の成否とバージョン変更の影響を切り分けられる計画にします。まず現在のバージョン、移行先のバージョン、公式の移行レポートを確認してください。n8nの2.0移行レポートと2.0の互換性変更は、バージョン固有の影響を調べるための資料です。2.0向けの説明を、別の版にもそのまま適用できるとは限りません。
n8n 2.xへ更新する前に何を確認しますか。
現在版と目標版の変更点、利用中のノードや設定への影響、公式資料が示す移行手順を個別に確認します。データベース移行の検証を先に完了させ、その後にバージョン更新を別工程として試すと、問題が起きた際に原因を判別しやすくなります。各工程の終了条件と、元の環境へ戻す条件も事前に決めてください。
切替後は役割ごとに動作を照合
以下を作業記録に残し、担当者ごとに確認します。
- [ ] 現行データベース、ワークフロー、認証情報、ユーザー設定のバックアップがある
- [ ] 移行対象から除外する実行履歴やバイナリデータについて、理由と保管方針が決まっている
- [ ] PostgreSQLの接続設定を公式資料で照合し、接続先と認証情報を安全に管理している
- [ ] 暗号化キーを確認し、移行後に保存済み認証情報を使えることを検証した
- [ ] 管理者と一般ユーザーの両方でログインし、ワークフローの可視範囲を確認した
- [ ] ワークフローの有効化、手動実行、スケジュールとWebhookによる起動を確認した
- [ ] 必要な実行記録と関連ファイルを開き、復元手順も試した
- [ ] 問題が起きた場合に旧環境へ戻す条件と担当者が決まっている
保存領域は、データベースの容量だけで判断しないでください。実行履歴の保持方針、バイナリデータの配置、バックアップ先、復元時に必要な空き領域を合わせて見積もります。PostgreSQLへ変更しただけで高可用性や自動バックアップが得られるわけではないため、冗長化とバックアップは別途設計します。
独占サーバーを検討する段階
共有型の仮想サーバーでは、他の利用者との資源競合や、選べるストレージ構成・システム環境の制限が運用上の課題になることがあります。n8nとPostgreSQLを長期稼働させ、データ配置や運用環境を自分たちで管理したい場合は、独占型のAMD物理サーバーも比較対象になります。
移行対象と必要な保存領域を整理できたら、XFP Cloudのサーバー情報で実際に選べるストレージ、システム、接続方法を確認し、利用期間と請求条件も照合してください。データベース移行の成功やバックアップを保証するものではないため、要件に合わない場合や短時間だけ使う負荷なら、現在の構成を維持する判断も合理的です。独占資源が必要で、長期にわたりn8nとPostgreSQLを運用する条件がそろう場合に、XFP CloudのAMD物理サーバーを候補として検討できます。
最終更新：2026年10月31日。n8nのデータベース設定、CLI、ワークフロー共有、実行データ、バイナリデータ、2.0関連の公式資料を参照し、バージョン固有の手順は対象環境で再確認してください。