先に結論
Supabase を本番で使っているなら、まず確認すべきは価格や新機能ではなく、まだ Postgres 14 が残っていないかです。
Supabase は 2026-07-01 で Postgres 14 のサポートを終了します。期日までに残っている project は自動アップグレード対象です。非対応拡張があると project pause になり、トラフィック停止の可能性があります。
今やることはシンプルです。
- project が Postgres 14 か確認する
- 非対応拡張を洗う
- downtime を置ける時間を確保する
- Postgres 17 でアプリが動くか先に試す
放置せず、手動で準備して上げたほうが安全です。
何が変わったのか
Supabase は 2026-05-12 の changelog で、Postgres 14 のサポートを 2026-07-01 に終了すると案内しました。
この告知で重いのは、単に古いバージョンが非推奨になるだけではないことです。7月1日時点で Postgres 14 の project は、自動で最新 Postgres へ上がる前提になっています。
ただし例外があります。Postgres 17 で使えない拡張が残っていると、自動アップグレードできません。その場合は project が pause され、リクエストをさばけなくなる可能性があります。
先に見るべき危険箇所
一番先に見るべきなのは拡張です。Supabase が changelog で明示しているのは次の5つです。
timescaledbplv8plsplcoffeepgjwt
これらは Supabase 上の Postgres 17 では使えません。SELECT * FROM pg_extension; か Extensions dashboard で、いま何が入っているか確認できます。
特に pgjwt は、明示的に使っていないつもりでも古い project では入っていることがあります。使っていないなら外せるかを早めに見たほうが安全です。
downtime は想像より軽いこともあるが、ゼロではない
upgrade はオンラインで無停止という話ではありません。Supabase は changelog で、小規模 DB なら約15分、大規模 DB なら1時間以上 の停止目安を出しています。
upgrading docs では in-place upgrade の目安として 約100MBps も案内されています。実際の所要時間は compute size や disk 構成で変わるので、本番時間帯に楽観で流すのは危険です。
先に downtime window を確保し、影響の少ない時間帯で実施したほうがいいです。
拡張以外で見落としやすい点
拡張以外にも、移行前に見ておきたい論点があります。
logical replication は自動で維持されない
upgrading docs では、logical replication の replication slot は upgrade 後に保持されないと案内されています。
CDC や外部同期を組んでいるなら、upgrade 後に slot を作り直す前提で作業手順を組む必要があります。
custom role の md5 password は移行が要る
Supabase 管理下の role は upgrade 中に scram-sha-256 へ寄せられます。自分で作った custom role は別です。
docs では、custom role の password を自分で更新しないと、upgrade 後に接続できなくなる可能性があると案内しています。運用用ユーザーや BI 接続用 role を作っているなら、ここも棚卸し対象です。
先に Postgres 17 でアプリを試したほうがいい
Supabase 自体も、新しい Postgres 17 project で既存アプリの互換性確認を勧めています。
SQL の挙動、拡張の置き換え、外部連携、監視周りまで含めて、先に別環境で確認しておくほうが事故を減らせます。
いますぐやるチェックリスト
作業を短く言うなら、次の順です。
- Dashboard で Postgres version を確認する
pg_extensionと Extensions dashboard で非対応拡張を洗う- logical replication と custom role の有無を確認する
- 低トラフィック時間帯の downtime window を押さえる
- 別環境で Postgres 17 互換を試す
- 7月1日を待たずに手動 upgrade する
この順なら、後から「pause 条件を見落としていた」「接続ユーザーだけ落ちた」を減らしやすいです。
Supabase を使い続けるべきか迷うなら
今回の話は、Supabase が危ないというより、定番 BaaS でも運用期限は必ず来るという話です。
backend 自体を見直すなら、AIエージェント時代のbackend比較記事 も参考になります。ただ、今回の期限対応で先にやるべきなのは乗り換え検討より既存 project の棚卸しです。
まとめ
Supabase の Postgres 14 サポート終了で一番危ないのは、期限そのものより 自動アップグレードに任せれば大丈夫だろうと考えること です。
非対応拡張が残っていれば pause の可能性があります。logical replication や custom role も、放置すると upgrade 後に効いてきます。
やるべきことは難しくありません。Postgres 14 かどうかを確認し、拡張と接続方式を洗い、downtime を押さえたうえで手動 upgrade を進める。それが 7月1日を安全に越える最短ルートです。