7 公開して運用する｜ブランチング・バックアップ・費用
作ったアプリを運用に乗せます。2026年に Git なしが既定になったブランチング、時間課金の落とし穴、プラン別のバックアップ、Free と Pro の費用の見方、そして情報の追い方を扱います。
このレッスンでわかること
機能はひととおり揃いました。最後に、壊さずに変更を続けるための仕組みと費用を押さえます。
- ブランチングで本番を壊さずにスキーマを変更できる
- ブランチが時間課金であることと、削除の運用がわかる
- プランごとのバックアップの違いがわかる
- Free と Pro の費用の見方がわかる
- 情報の追い方がわかる
手順は 2026-08 時点のものです。
ブランチング
第2章でマイグレーションを残しました。ただし supabase db push は本番に直接適用します。列の削除や型の変更を含む変更を、いきなり本番へ流すのは怖い操作です。
ブランチングは、本番と同じ構成の別プロジェクトを一時的に立てて、そこで試す仕組みです。
2026-05-04 に既定が変わった
以前のブランチングは GitHub 連携が前提で、プルリクエストに対して環境が立ち上がる形でした。2026-05-04 に、Git なしでブランチを作るのが既定になりました。
- ダッシュボードから直接ブランチを作れる
- 変更して、差分をプレビューして、マージする
- GitHub 連携は任意になり、両方のやり方が公式にサポートされている
差分の計算に使うエンジンも変わりました。ダッシュボードのブランチングの既定エンジンが migra から pg-delta に置き換わっています。Postgres 固有の DDL への対応が広がったと説明されていますが、**pg-delta 自体は alpha 段階のソフトウェアだと公式に明記されています。**生成された差分をそのまま信用せず、内容を読んでください。
**ステータスの表記が公式ドキュメント内で揃っていません。**ブランチングのガイドや機能一覧では Beta 相当の表記が使われている一方、ダッシュボード経由のブランチ操作を説明するページには「public alpha」と書かれています。本番のクリティカルな変更で頼り切る段階ではないと考えておく方が安全です。
CLI から使う
CLI には次のコマンドが用意されています。
npx supabase branches create <ブランチ名>
npx supabase branches list
npx supabase branches get <ブランチ名>
npx supabase branches delete <ブランチ名>create には --persistent（永続ブランチ）、--region、--size、--with-data などのフラグがあります。一時停止・再開は pause / unpause です。
費用に直結する注意
ここが本章でいちばん実害が出やすい部分です。
| 項目 | 内容 |
|---|---|
| 料金 | 1ブランチあたり 1時間 $0.01344 から（既定の Micro Compute の場合） |
| 対象プラン | Pro 以上。Free では使えない |
| 課金対象 | ブランチ環境の Compute / Disk / Egress / Storage が、本番プロジェクトと同じように課金される |
時間課金です。**消し忘れたブランチは、誰も使っていなくても課金され続けます。**1時間 $0.01344 は小さく見えますが、24時間 × 30日で計算すると1ブランチあたり月 $9.6 ほどになります（Micro 基準の下限からの単純計算です）。3本放置すれば、Pro プランの基本料金と同じくらいの額になります。
公式のコスト削減の案内にも「使っていない Preview ブランチは削除する」が挙げられています。
運用として決めておくことは2つです。
- 作ったら消す担当を決める。
supabase branches listを定期的に見る運用にします - **GitHub 連携を使うなら、自動削除が効く。**Preview ブランチはプルリクエストがマージまたはクローズされた時点で自動的に削除されます
Git なしで運用する場合、この自動削除がありません。手で消す前提の運用になることを最初に認識しておいてください。
ダッシュボードからブランチを削除する具体的な手順は、公式ドキュメントの該当ページで確認できていません。CLI の
supabase branches deleteは確実に使えます。
バックアップ
プランによって、あるものと無いものがはっきり分かれます。
| プラン | 自動バックアップ |
|---|---|
| Free | 提供されない |
| Pro | 直近 7日の日次バックアップ |
| Team | 直近 14日 |
| Enterprise | 最大 30日 |
**Free プランには自動バックアップがありません。**公式は CLI の db dump による自己エクスポートを勧めています。
npx supabase db dump --linked -f backup.sql学習用のプロジェクトなら気にしなくてよいのですが、Free のまま実際の問い合わせを受け始めたら、自分でバックアップを取る仕組みが要ります。
PITR（Point-in-Time Recovery、任意の時点への復旧）は、Pro 以上で使える有料のアドオンです。保持期間ごとに料金が分かれています（7日で月 $100、14日で月 $200、28日で月 $400）。
Free プロジェクトの一時停止
もう1つ、Free プランで知っておくべき挙動があります。
**アクティビティが1週間無い Free プロジェクトは一時停止されます。**停止後は1年以内であれば Supabase Studio から復元できます。
学習用に作ったプロジェクトを久しぶりに開いたら止まっていた、というのはこれです。本番として使うなら Pro にする、という判断の材料になります。
費用の見方
Free プランに含まれるもの
| 項目 | 上限 |
|---|---|
| 月間アクティブユーザー（MAU） | 50,000 |
| データベース容量 | 500MB（Shared CPU / 500MB RAM） |
| Egress（転送量） | 5GB |
| ファイルストレージ | 1GB |
| Edge Functions の呼び出し | 500,000回 |
**MAU 50,000 はかなり大きい数字です。**個人開発や小規模な業務システムで、認証の枠が先に足りなくなることはまず起きません。
**先に当たるのはデータベースの 500MB と Egress の 5GB です。**問い合わせフォームなら本文はテキストなので容量は伸びませんが、添付ファイルを大量に受けると 1GB のファイルストレージが先に埋まります。
Pro プラン
- 月 $25 から
- **月 $10 分の compute credits が含まれる。**これは Micro インスタンス1台分をカバーする額
- 超過分については spend cap（利用上限）が既定でオンになっており、オフにすると従量課金に切り替わる
**spend cap が既定でオンなのは重要な性質です。**知らないうちに請求が膨らむことは起きにくい代わりに、**上限に達するとサービスが制限されます。**本番で使うなら、どちらの挙動を望むかを最初に決めてください。
どこで費用が増えるか
このコースの題材で費用が伸びやすいのは、次の順です。
- ブランチの消し忘れ（時間課金。放置が効く）
- 添付ファイルの蓄積（ストレージ容量と Egress の両方に効く）
- compute のサイズ（Micro を超えると compute credits を食い切る）
1番が最も「気づかないうちに増える」種類です。第5章で fileSizeLimit を設定したのは、2番への予防でもあります。
公開前のチェック
第7章まで来たので、公開前に確認するものを並べます。
| 確認 | 章 |
|---|---|
| すべてのテーブルで RLS が有効になっている | 第3章 |
| 各テーブルのポリシーを、publishable key で実際に叩いて確認した | 第3章 |
ビューに security_invoker = true が付いている | 第3章 |
| ダッシュボードの Advisors に指摘が残っていない | 第3章 |
| カスタム SMTP を設定した（既定は1時間2通） | 第4章 |
| Site URL と Redirect URLs が本番の URL になっている | 第4章 |
| Storage のバケットが非公開で、サイズと種類の制限が入っている | 第5章 |
| secret key と外部 API キーがクライアント側に含まれていない | 第6章 |
マイグレーションだけでスキーマを再現できる（supabase db reset が通る） | 第2章 |
**4番目と5番目を忘れがちです。**Advisors は無料で使えるチェックなので、公開前に必ず開いてください。
2026-10-30 の変更を思い出す
第2章で触れた変更を、運用の観点で再掲します。
**2026-10-30 に、public スキーマの新しいテーブルを Data API へ自動公開しない変更が、既存のすべてのプロジェクトへ適用されます。**既存のテーブルは影響を受けませんが、その日以降に作るテーブルは、grant を書かないと API から見えません。
「テーブルを作ったのにアプリから 404 や空が返る」という症状が出たら、まずこれを疑ってください。本コースでは最初から自動公開を切った前提で書いたので、すでにその運用になっています。
情報の追い方
Supabase の変更は速く、**このコースに書いた仕様も変わります。**追い方を決めておいてください。
- **Changelog を見る。**機能追加も廃止予告も、まずここに出ます。本コースで扱った「Free プランのメールテンプレート制限」「Node.js 20 のサポート終了」「Data API の自動公開停止」は、いずれも公式ドキュメント本文ではなく Changelog が一次資料でした
- **ダッシュボードの Advisors を定期的に開く。**設定漏れは、ドキュメントを読むより先にここに出ます
- **CLI のバージョンを上げる。**コマンドのフラグは追加・変更されます
番号付きの Launch Week は 2025-07 の LW15 が最後です。**「次の Launch Week を待つ」という追い方は現在は成立しません。**Changelog を定期的に見るのが現実的な方法です。
3つのコースを見比べる
同じ題材を3つのやり方で作りました。改めて並べると、選び方の基準が見えます。
| Cloudflare | Vercel | Supabase | |
|---|---|---|---|
| データ保存 | D1 | 外部サービスを接続 | Postgres（内蔵） |
| ファイル保存 | R2 | 外部サービスを接続 | Storage（内蔵） |
| アクセス制御の置き場所 | Workers のコード | Route Handlers のコード | データベースの中（RLS） |
| 一般ユーザーのログイン | 扱えない | 扱えない | 扱える |
| フロントエンドの配信 | 得意 | 得意 | 担当しない |
**Supabase の特徴は、アクセス制御がコードではなくデータベースの中にあることです。**これは慣れると強力で、クライアントを何個作っても同じルールが効きます。一方で、RLS を書き忘れた瞬間にデータが公開されるという性質も、同じ設計から来ています。
最後の行も見てください。**Supabase はフロントエンドを配信しません。**実務では、画面を Cloudflare や Vercel に置き、データを Supabase に置く組み合わせがよく取られます。3つは競合というより、重なりのある別の役割です。
- Cloudflare 入門コース — 同じ題材を Workers / D1 / R2 で
- Vercel 入門コース — 同じ題材を Next.js と Vercel で
- Cloudflare / Vercel / Supabase の選び方 — 作るものの性質から選ぶ
このコースを終えたら、機能ごとの詳細は Supabase リファレンスを必要なときに引いてください。
やってみよう
- ブランチを作る：Pro プランを使っている場合、
npx supabase branches create test-branchでブランチを作り、branches listで確認します - 必ず消す：確認が終わったら
npx supabase branches delete test-branchを実行します。この演習は消すところまでが本体です - バックアップを取る：
npx supabase db dump --linked -f backup.sqlを実行し、中身を開いてみます - 使用量を見る：ダッシュボードの使用量画面で、いまどの項目がどれだけ使われているかを確認します
- 公開前チェックを1つずつ潰す：上の表を使って、自分のプロジェクトを確認します
- Advisors を開く：指摘が出ていないことを確認します。出ていたら、どの章の内容かを考えてから直します
6番で指摘が出た場合、**答えを見る前に自分でどの章の話かを当ててみてください。**ここまでの理解が試せます。
まとめ
- **2026-05-04 から Git なしのブランチングが既定。**GitHub 連携は任意になり、差分エンジンは pg-delta に置き換わった。ただし pg-delta は alpha、ダッシュボード経由の操作は public alpha 表記
- **ブランチは時間課金（1時間 $0.01344 から、Pro 以上）。消し忘れが積み上がる。**Git 連携なら PR のマージ・クローズで自動削除されるが、Git なし運用では手で消す
- Free プランに自動バックアップは無い。
supabase db dumpで自分で取る。Pro は7日、Team は14日 - **Free プロジェクトは1週間の非アクティブで一時停止される。**復元は1年以内なら可能
- Free の枠は MAU 50,000 / DB 500MB / Egress 5GB / ファイル 1GB / Edge Functions 50万回。先に当たるのは DB 容量とファイル容量
- Pro は月 $25 から、月 $10 分の compute credits 込み。spend cap は既定でオン
- 2026-10-30 に Data API の自動公開停止が全プロジェクトへ適用される
- 情報は Changelog と Advisors で追う。番号付きの Launch Week は 2025-07 の LW15 が最後
理解度チェック
Q1. Pro プランでブランチを3本作り、そのまま1か月放置しました。何が起きるでしょう？
- 使っていないので課金されない
- 30日後に自動的に削除される
- 1本ずつ時間課金され続ける
- Free プランに自動的にダウングレードされる
答えを見る
正解：3
ブランチは1本あたり1時間 $0.01344 から（既定の Micro Compute の場合）の時間課金で、使っていなくても存在する限り課金されます。自動削除が働くのは GitHub 連携を使っていて、対応するプルリクエストがマージまたはクローズされた場合だけです。Git なしで運用している場合は、supabase branches delete で自分で消す必要があります。
Q2. Free プランのプロジェクトで、データベースのバックアップを確保する方法として正しいのはどれでしょう？
- 自動で日次バックアップが取られるので何もしなくてよい
- PITR アドオンを有効にする
supabase db dumpで自分でエクスポートする- ブランチを作っておけばバックアップになる
答えを見る
正解：3
Free プランには自動バックアップが提供されていないため、公式も CLI の db dump による自己エクスポートを勧めています。PITR は Pro 以上で使える有料アドオンで、ブランチングも Pro 以上の機能である上に、バックアップを目的とした仕組みではありません。
参考リンク
- Branching Without Git Is Now The Default（Supabase Blog） — 2026-05-04 の変更内容と pg-delta
- Branching（Supabase 公式） — ブランチングの全体像とステータス表記
- Manage Branching usage（Supabase 公式） — 時間課金の内訳とコスト削減の指針
- Backups（Supabase 公式） — プラン別の保持期間と PITR
- Project Pausing（Supabase 公式） — Free プロジェクトの一時停止と復元
- Supabase Pricing — 各プランの枠と超過の扱い