Neon から移行する

どちらも PostgreSQL を提供します。違うのはその下です。Neon はストレージと計算を分離し、ストレージ層でブランチを作ります。CapyDB は専用ストレージ上で普通の PostgreSQL プロセスを動かし、そのストレージをクローンしてブランチにします。体感する帰結は、CapyDB のセルが手元のノート PC の Postgres と同じように振る舞うこと。実際に同じものだからです。

スキーマ、クエリ、拡張機能、マイグレーションはそのまま移ります。注意が要るのは接続層と、事業者固有のドライバーに合わせて書かれた部分です。

• -ブランチ：プレビュー用データベースは有効期限つきのクローン。プルリクエストごとに 1 つ
• -ゼロスケール：アイドルのセルは眠り、次の接続で目覚めます。通常 0.25 秒以内
• -サーバーレスやエッジ向けのプール接続と、それ以外のための直接接続
• -夜間スナップショットではなく継続的アーカイブからの任意時点への復元
• -すでにお使いのデプロイ先向けのプラットフォーム連携

• -HTTP／WebSocket ドライバーはありません。どのドライバーもすでに話せる PostgreSQL のワイヤープロトコルで接続します
• -分離はプロジェクトごとのプロセス丸ごととストレージであって、共有計算層の中のテナントではありません
• -計算資源はプランごとの固定した CPU・メモリ上限で、自動スケールする単位ではありません
• -標準セルには外向きのネットワークがないため、外部を呼ぶ拡張機能は構造上使えません

プロジェクトが Neon 固有のサーバーレスドライバーを取り込んでいる場合、CLI が書き換えます。コードモッドはクライアントを標準の PostgreSQL ドライバーに差し替え、接続の初期化を直し、判断がつかない呼び出し箇所は推測せずに報告します。

# Dry run by default - nothing is written until you say so
capydb migrate codemod neon
capydb migrate codemod neon --write

既存の接続文字列に対してインポートを開始します。フォローモードがテスト中も新しいセルを移行元と同期させ続けるので、切り替えはメンテナンス時間ではなく DNS と環境変数の変更で済みます。

capydb import \
  --project my-app \
  --source-url "$OLD_DATABASE_URL" \
  --follow

• -フォロー付きでインポートし、そのまま動かしながらテストスイートをセルに対して実行する
• -capydb doctor を走らせ、まだ旧データベースを指す環境変数を洗い出す
• -デプロイ先の接続文字列を差し替える。連携機能なら環境ごとに実行できます
• -最初の数分はダッシュボードでログと接続数を見張る
• -納得できたらフォローを止め、移行元を停止する

本番の切り替えは、始める前にお知らせください。計画を確認し、その時間帯に待機し、復旧経路を用意しておきます。費用はかかりませんし、退屈な夜と面白い夜の分かれ目になります。