先に結論
self-hosted Supabase を default tag のまま更新しているなら、6月17日より前に「PG 17 へ上げるか」「PG 15 に pin するか」を決める必要があります。
Supabase は 2026-06-17 週の次回 release で、self-hosted docker-compose.yml の default db image を Postgres 15 から 17 へ切り替えます。ここで一番危ないのは、既存データが PG 15 のままなのに compose だけ更新することです。
PG 15 の data directory は自動移行されません。default tag を追ったまま docker compose pull && up -d すると、PG 17 コンテナが古い volume を読めず起動失敗する可能性があります。
誰が対象か
対象はかなりはっきりしています。
Supabase が挙げているのは、次の3条件をすべて満たすケースです。
./docker配下の self-hosted Supabase を使っているsupabase/postgresの image tag を pin せず default のまま追っている- 既存データが Postgres 15 にある
逆に、Supabase の managed platform を使っている人は対象外です。supabase start を使った local development も別系統なので、今回の切り替えは直接は当たりません。
fresh deployment だけなら話は軽くなります。既存データがないなら、docker-compose.pg17.yml を使って最初から PG 17 で始めれば済みます。
何が変わるのか
今回の変更は「いつか上げてください」ではありません。default image を追っているだけで、次回 release から実際に前提が変わるのが重いところです。
Supabase は changelog で、2026-04-08 に PG 17 を opt-in で出し、2026-05-18 に breaking change を告知し、2026-06-17 に default を切り替える流れを明示しています。
つまり、何もしないことが現状維持ではありません。既存の PG 15 運用を続けたいなら、自分で supabase/postgres:15.x に pin する必要があります。
一番先に見るべき危険箇所
最初に見るべきなのは、既存 volume をそのまま読めると思い込まないことです。
Postgres 17 は PG 15 の data directory を直接読めません。公式 guide でも、既存 deployment は pg_upgrade を使ってデータを移す前提になっています。
もう1つ先に見るべきなのが extension です。Supabase の PG 17 build では、次の extension は使えません。
timescaledbplv8plcoffeeplls
これらを手動で入れているなら、upgrade script を回す前に止まる可能性があります。必要なら upgrade を急がず、まず PG 15 pin で事故を止めるほうが安全です。
いま取れる選択肢は2つ
1. 既存データを守りながら PG 17 へ上げる
既存データを残すなら、公式の upgrade-pg17.sh を使うルートが本命です。
この script は、temporary な PG 15 / PG 17 コンテナを使って pg_upgrade を実行し、extension の再有効化、patch 適用、VACUUM ANALYZE、role migration まで面倒を見ます。元の data directory は data.bak.pg15 として残るので、rollback 余地もあります。
ただし、気軽に実行していい作業ではありません。docs では DB サイズの 2 倍 + 5GB 以上の空き容量、pgsodium key を含む backup、root か sudo 実行を前提にしています。
2. いったん PG 15 に pin して先送りする
6月17日までに移行準備が終わらないなら、まずは事故を止めるべきです。
その場合は docker-compose.yml の db image を supabase/postgres:15.x に pin します。Supabase は PG 15 image 自体は引き続き公開すると案内しています。
この方法なら、default 切り替えに巻き込まれず、extension 棚卸しや disk 容量確保を先に済ませられます。運用としては一番摩擦が少ない回避策です。
backup は data directory だけでは足りない
見落としやすいのは pgsodium の root key です。
公式 guide では、./volumes/db/data のコピーに加えて、Docker named volume にある pgsodium_root.key の退避も勧めています。Vault secret を使っているなら、この key を失うと復旧できません。
加えて、logical backup も取っておくほうが安全です。disk 破損や作業ミスまで考えると、script が残す data.bak.pg15 だけに頼るのは少し怖いです。
upgrade 後に見落としやすい点
upgrade が通っても、それで終わりではありません。
replication slot は持ち越されない
docs では、active replication slot があると pg_upgrade が失敗すると案内しています。logical replication を組んでいるなら、slot を落としてから upgrade し、あとで作り直す前提で runbook を組む必要があります。
compose 運用が少し変わる
PG 17 へ上げたあとに override file を使う構成なら、docker-compose.yml と docker-compose.pg17.yml の両方を指定して起動する運用になります。新規 deployment 側でもこの前提です。
custom config と権限も確認したい
PG 17 image は /etc/postgresql-custom/conf.d/ 配下の .conf を読みます。Postgres 15 とは挙動が違うため、手元の custom config があるなら起動後に再確認したほうが安全です。
まずやるチェックリスト
順番を短くすると、やることは次の6つです。
- self-hosted か、managed / CLI local development かを切り分ける
supabase/postgresを pin しているか確認する- 既存 DB が PG 15 か、fresh deployment かを確認する
timescaledb、plv8など非互換 extension の有無を洗う- 空き容量と backup、
pgsodiumkey 退避を準備する - 間に合わないなら先に
15.xpin、いけるなら upgrade script を試す
この順なら、6月17日に近づいてから慌てて compose 更新事故を踏む確率をかなり下げられます。
すでに Supabase を追っている人向けの次の読み先
今回の変更は self-hosted 特有ですが、Supabase 全体でも運用判断が続いています。
managed project 側の期限を確認したいなら、Postgres 14 サポート終了の記事 がつながります。権限委譲まわりを見直すなら、一時 DB アクセス preview の記事 が役立ちます。
GraphQL を使っているなら、pg_graphql 1.6.0 の introspection 既定 OFF 記事 も一緒に見ておくと、6月以降の runbook 更新をまとめて進めやすいです。
Supabase 自体を使い続けるか見直したい人は、backend 比較記事 も参考になります。ただ、今回先にやるべきなのは比較より self-hosted の事故回避です。
まとめ
Supabase self-hosted の PG 17 default 化で一番危ないのは、default tag を追っているだけなのに現状維持だと思い込むことです。
既存の PG 15 volume があるなら、自動では上がりません。upgrade script で上げるか、supabase/postgres:15.x に pin して後ろ倒しするかを、6月17日より前に決める必要があります。
まずは対象条件、extension、backup、空き容量を確認してください。そこまで見えれば、自分たちが今すぐ上げるべきか、いったん pin で止血すべきかはかなり判断しやすくなります。