先に結論
self-hosted Supabase を ./docker 構成で運用しているなら、6月中旬の compose 更新前に owner migration の要否を確認したほうが安全です。
Supabase は 2026-06-17 週の release で、Studio と postgres-meta が使う DB role を supabase_admin から postgres へ切り替えます。既存環境では、public schema の object owner が supabase_admin のまま残っていることがあるため、そのまま更新すると Studio 側の操作が失敗しやすくなります。
やることは多くありません。sh utils/reassign-owner.sh を一度実行し、compose の関連変数を postgres にそろえ、最後に select current_user; で確認すれば流れは追えます。
誰が対象か
対象はかなり絞られます。
Supabase が挙げているのは、./docker 配下の self-hosted Supabase を使い、compose 更新で upstream の docker-compose.yml を取り込む既存環境です。Studio 経由で作った object が残っているほど、今回の差分が効きます。
逆に、Supabase の managed platform を使っているチームは対象外です。supabase start を使うローカル開発も別経路なので、今回の切り替えをそのまま受けるわけではありません。
fresh install なら話は軽くなります。最初から postgres ownership で始まるため、既存 object を移す作業は不要です。
何が変わるのか
変わるのは Studio 周辺が使う role です。
Supabase は default の docker-compose.yml で、studio.environment.POSTGRES_USER_READ_WRITE と meta.environment.PG_META_DB_USER を postgres に切り替えます。self-hosted 側を managed platform の挙動に寄せる変更で、superuser 権限に寄り過ぎていた旧挙動をたたむ意図があります。
ここで引っかかるのは、既存環境の object owner です。過去の self-hosted 環境では、Studio から作った object が supabase_admin owner のまま残っていることがあります。role だけ postgres に切り替わると、その差分が失敗要因になります。
先に見るべき危険箇所
一番先に見るべきなのは、既存 object がどの schema にあるかです。
公式 script が自動で触るのは public schema だけです。ここにある table や view なら sh utils/reassign-owner.sh で owner を移せます。
一方で、custom schema は自動移行されません。self-hosted 運用で schema を切っているなら、public だけ直して終わりとは限りません。custom schema 側の owner も別途見ておく必要があります。
もう1つ見落としやすいのが override です。POSTGRES_USER_READ_WRITE や PG_META_DB_USER を自前の override file で固定している環境では、upstream の compose を pull しても実際の挙動が変わらないことがあります。逆に、気づかないまま一部だけ切り替わると追跡が面倒になります。
実際にやること
1. public schema の owner を移す
既存環境なら、まず one-time migration を実行します。
sh utils/reassign-owner.shこの script は public schema の object owner を supabase_admin から postgres へ移します。managed schema や custom schema には触れません。
2. compose の role 設定をそろえる
次に、Studio と postgres-meta が postgres を使うようにそろえます。
見る場所は 2 つです。
studio.environment.POSTGRES_USER_READ_WRITEmeta.environment.PG_META_DB_USER
default compose をそのまま使うなら upstream 更新で変わります。override file を持っているなら、自分の compose 側でも postgres へ寄せる必要があります。
3. 再起動して SQL Editor で確認する
変更後は stack を再起動し、Studio SQL Editor で select current_user; を実行します。
返り値が postgres なら、最低限の切り替えは通っています。ここまで見れば「変数だけ変わった」「owner だけ古いまま残った」といった中途半端な状態を避けやすくなります。
すぐ移行したくないときの考え方
今回の変更は default の切り替えであって、supabase_admin そのものが即削除されるわけではありません。
そのため、custom schema の棚卸しがまだ終わらないなら、override file で従来値を維持して一度止血する選択肢もあります。ただし、それは恒久対応ではありません。managed platform との挙動差分を残したままになるため、運用差分を増やしたくないなら早めに postgres へ寄せたほうが後が楽です。
いま確認しておくと楽なチェックリスト
順番を短くすると、先に見るべきなのは次の5点です。
- self-hosted が
./docker構成かどうか - 既存環境か fresh install か
publicschema にsupabase_adminowner の object が残っていないか- custom schema を持っていないか
- override file で role 変数を固定していないか
ここまで見えていれば、6月中旬の release を pull したときに慌てにくくなります。
あわせて見ておきたい Supabase 運用記事
self-hosted を追っているなら、PG 17 default 化の整理記事 もつながります。6月中旬は role だけでなく DB image 側の変更も近いため、compose 更新をまとめて確認したい人に向いています。
Node runtime 側の棚卸しが残っているなら、Node.js 20 サポート終了の記事 も合わせて見ておくと、6月末までの作業を並べやすくなります。
権限まわりの運用を広く見たいなら、一時 DB アクセス preview の記事 や Supabase 比較記事 も参考になります。ただ、今回先にやるべきなのは比較より owner migration の確認です。
まとめ
Supabase self-hosted の今回の変更で見るべきなのは、Studio の role が postgres へ移ること自体より、既存 object owner との食い違いが残らないかです。
既存環境なら sh utils/reassign-owner.sh、compose 変数の切り替え、select current_user; の確認までを 1 セットで進めてください。custom schema と override file だけ先に洗っておけば、6月中旬の compose 更新で詰まる確率はかなり下げられます。