Supabase から移行する

データベースだけでなく認証・ストレージ・エッジ関数・リアルタイムまで Supabase を使っているなら、CapyDB への移行は 1 つではなく 4 つの製品を置き換えることになります。それが正しい判断のこともあります（多くは、アプリがその結合を卒業したときです）が、午後で終わる作業ではなくプロジェクトです。

主にホスティングされた Postgres として Supabase を使っていて、残りは付随的だというなら、これは素直な移行です。以降はまさにそのためのページです。

• -スキーマ、データ、インデックス、制約、関数、トリガー
• -拡張機能。セルごとに有効化するカタログ経由で
• -マイグレーション。どのツールが生成したものでも
• -あらゆるクライアントライブラリ。接続文字列は普通の postgres:// URL だからです

Supabase の行レベルセキュリティポリシーは、同社の auth スキーマと JWT クレーム用ヘルパーに依存して書かれています。それらは Supabase の外に存在しないため、単純なダンプとリストアでは、ない関数を参照するポリシーだけが残ります。

CLI が変換します。コンバーターはオープンソースで、ポリシーを素の PostgreSQL のセッション設定に対して書き直し、翻訳できなかったものは黙って緩い出力を出すのではなく報告します。

capydb migrate rls ./supabase --out capyrls

• -認証：専用の ID プロバイダーへ移し、変換後のポリシーが読むセッション設定に同じクレームを入れる
• -ストレージ：オブジェクトストレージと署名付き URL。コードモッドは一般的なバケットの意味づけを対応させ、残りは報告します
• -エッジ関数：デプロイ先がすでに動かしているもの。ただのサーバーレス関数です
• -リアルタイム：PostgreSQL の論理レプリケーションと LISTEN/NOTIFY がどちらもセルで使えます
• -データベース本体：ここが本当に「そのまま持っていく」部分です

Supabase の接続文字列から直接インポートします。インポーターは持っていくべきでないプラットフォームのスキーマを把握して除外するので、手元に残るのは自分のデータで、他人のコントロールプレーンの複製ではありません。

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

• -フォロー付きでインポートし、移行元が生きているあいだにテストスイートをセルへ実行する
• -変換後のポリシーを適用し、スーパーユーザー接続ではなく実際のセッションで検証する
• -capydb doctor を走らせ、まだ旧プロジェクトを指す環境変数を洗い出す
• -環境ごとに接続文字列を差し替え、ログを見張り、そのあとフォローを止める
• -移行元は読み取り専用で 1 週間残す。費用はわずかで、実際に人を救ってきました

本番の切り替え前にお知らせください。計画を確認し、その時間帯に待機し、復旧経路を用意しておきます。