Supabase RLS コンバーター

Supabase の RLS は、標準の CREATE POLICY に Supabase だけが提供するコンテキストを加えたものです。auth.uid() と auth.jwt()、anon・authenticated・service_role の各ロール、そしてリクエストごとに注入される JWT です。プロジェクトを Supabase に縛りつけているのは、ポリシーではなくこのコンテキスト層です。

コンバーターはこの層をまるごと移し替えるので、ポリシーは素の Postgres で動き、同じ認可を続けます。

• -auth.uid()、auth.jwt()、auth.role()、auth.email() は、トランザクションローカルな設定を読むアクセサ関数になり、JWT の各クレームはそれぞれ独立した設定になります。
• -TO anon と TO authenticated は述語になり、service_role は制限ポリシーも通過するサービス経路になります。
• -FOR ALL ポリシーはコマンドごとに分割され、default auth.uid() のような列のデフォルト値は書き換えられます。
• -レポートには、アプリケーションがデータベースに対して設定すべき値が並びます。これが統合のチェックリストです。

デフォルトの Vanilla は、素の Postgres らしい構成です。アプリが呼び出し元を検証し、トランザクションごとに型付きの事実（app.user_id、app.org_id）を設定します。データベースは JWT について何も知りません。

Supabase 互換は、そのまま引っ越すための方式です。request.jwt.claims を読む auth.* シムにより、ポリシーはほぼそのまま移行できます。サービス経路はクレームの role です。"role": "service_role" は、サービスキーを使っていたサーバーコードからだけ設定してください。

どちらも CapyDB では単一ロールモデルで動きます。セルの所有者が接続し、行セキュリティを FORCE し、ロールの作成は不要です。

機械的に移行できないものは、誤って変換せずにレポートします。

• -auth.users を参照するポリシー。このテーブルは Supabase に残るため、必要な列を先に移してください。
• -storage や realtime など、Supabase が管理するスキーマ上のポリシー。
• -auth.* を呼び出す関数本体と、それに依存するポリシー。
• -FORCE されたテーブルに書き込む SECURITY DEFINER 関数（行セキュリティを迂回できなくなります）と、その修正方法。EXECUTE 経由の書き込みは検出されません。

コンバーターは、WebAssembly にコンパイルした capyrls です。ページはこれを静的ファイルとして一度だけ取得します。SQL はテキストボックスと選んだファイルから読み込まれ、ページ内で変換され、ダウンロードとして返されます。

アカウント不要、アップロードなし、貼り付けた内容の記録もありません。ブラウザを使いたくない場合は、同じエンジンが CLI でも動きます。

capydb migrate rls は、このコンバーターをリポジトリに対して、あるいは最も正確には稼働中の Supabase データベースに対して実行します。capyrls は MIT ライセンスで、移行先がどの Postgres でも使えます。

# from your repo (finds supabase/migrations) or straight from the live database
$ capydb migrate rls
$ capydb migrate rls --source-url "$SUPABASE_DIRECT_URL" --uid-type text

# standalone, MIT, any Postgres
$ go install github.com/capydatabase/capyrls/cmd/capyrls@latest
$ capyrls convert supabase/migrations