Supabase で予想外の従量課金を止める — バイブコーダーに DB を安全に渡すための Spend Cap 設定

「バイブコーディング」という言葉が一般化し、コードをほとんど書かない人でも Supabase のような BaaS を使ってアプリを動かす時代になりました。社内のノンデベロッパーや、顧客向けのプロトタイピング用途に対して、Supabase のデータベースをそのまま渡したい場面も増えています。

そこで最初に立ちはだかるのが課金の不安です。Supabase はプランごとに無料枠（クォータ）があり、それを超えると従量課金されるハイブリッド型の料金体系を採用しています。ノンデベロッパーは「Egress」や「MAU」といった単語の意味も、それが課金にどう響くかも基本的に知りません。渡した相手が大量のデータを流したり、無限再接続ループのあるコードを動かしたりした結果、月末に予想外の高額請求が届く、という事故は十分に起こりえます。

そこで気になるのが「Supabase には、無料枠を超えた分を従量課金しない設定があるのか」という一点です。本記事はこれを 2026 年 6 月時点の Supabase 公式ドキュメント・料金ページに基づいて調査し、安全に DB を渡すための構成までまとめたものです。料金やポリシーは変動が激しいため、本番採用の前には必ず確認日基準で公式ページを当たってください。

結論 — 定額に固定できるのは Free と Pro（Spend Cap オン）だけ

先に結論を述べます。超過時の挙動はプランと設定によって次の 2 つに分かれます。

定額のまま（超過分を課金しない）: Free プラン、Pro プラン + Spend Cap オン（デフォルト）。クォータを超えると課金ではなくサービス側が制限される。
従量課金（超過分を GB 単位などで課金）: Pro プラン + Spend Cap オフ、Team プラン、Enterprise プラン。サービスは止まらず、超過分が請求に上乗せされる。

つまり「予想外の従量課金を止めたい」という要件に対する答えは、Free プランを使うか、Pro プランで Spend Cap（支出上限）をオンのままにすることです。Spend Cap は Pro プランのデフォルトでオンなので、わざわざオフにしない限り、Pro でも料金は定額に固定されます。逆に Team プラン以上には Spend Cap という概念そのものが存在せず、超過は常に従量課金される点に注意が必要です。

公式ドキュメントの各「Manage your usage」ページは、この境界をいずれも次のように明記しています。「有料プランで Spend Cap をオフにしているか、組織が Team プラン以上の場合は、超過分を支払うことになる」。裏を返せば、それ以外（Free と Pro + Spend Cap オン）では超過分の課金は発生しません。

課金は組織単位で動く

仕組みに入る前に、Supabase の課金の単位を押さえておきます。Supabase の課金は「プロジェクト」ではなく「組織（Organization）」単位です。各組織が単一のプラン（Free / Pro / Team / Enterprise）を持ち、無料枠は組織全体に適用されます。組織内に複数のプロジェクトがある場合、その使用量は合算してクォータと比較されます。

したがってノンデベロッパーに DB を渡すときは、誰のどのプロジェクトがどの組織に属しているかが、そのまま課金リスクの境界線になります。リスクを切り分けたいなら、相手ごと・用途ごとに組織を分けるのが基本です。後述しますが、開発・検証用とユーザー提供用で組織を分け、それぞれに適切なプランと Spend Cap 設定を割り当てるのが安全な設計になります。

Spend Cap の仕組み — Pro 専用の二択トグル

Spend Cap（支出上限）は、組織がプランのクォータを超過できるかどうかを決めるトグルです。公式ドキュメントは「この機能は Pro プランでのみ利用可能」と明記しており、Team・Enterprise には存在しません。

Spend Cap オンの場合（定額）は、クォータを超えるとその項目の追加利用が次の請求サイクルまで禁止され、超過課金は発生しません。料金は基本料金（Pro は $25/月）にコンピュート費用を加えた額で固定されます。

Spend Cap オフの場合（従量課金）は、プロジェクトは止まらず稼働を続け、超過分が料金ページの単価で課金されます。トラフィックが急増してもシームレスにスケールしますが、その分だけ請求が膨らみます。

ここで重要な制約が 2 つあります。1 つ目は、Spend Cap が金額ベースの上限ではないことです。公式ドキュメントは Spend Cap について「きめ細かいコスト管理はできない」と明記しており、「月 $100 まで」のような予算上限の設定や、特定金額に達したときの通知といった機能は提供されていません。提供されるのは完全ブロックか完全従量かの二択だけです。これは長年ユーザーから機能要望が出ている既知の制約です。

2 つ目は、AWS Marketplace 経由で管理される組織では Spend Cap が利用できない（常に従量課金）という点です。課金を完全に固定したいなら、組織を AWS Marketplace 経由ではなく Supabase 直契約で作成する必要があります。

Spend Cap でカバーされる項目・されない項目

ノンデベロッパーに渡すうえで最も重要なのが、Spend Cap オンでも「保護されない（常に課金される）項目」が存在するという事実です。ここを理解せずに「Spend Cap オンだから絶対に課金されない」と思い込むと、想定外の請求につながります。

Spend Cap オンでブロックされる（＝定額に収まる）項目は次のとおりです。

ディスクサイズ（データベース容量）
Egress（統合データ転送量）
Edge Function の呼び出し回数
ログの取り込み・クエリ（Logs Ingest / Query）
MAU（月間アクティブユーザー、通常・SSO・サードパーティ）
Realtime のメッセージ数・ピーク同時接続数
Storage の画像変換
ストレージサイズ（ファイル容量）

一方、Spend Cap オンでも常に課金される（保護対象外の）項目は次のとおりです。

Compute（コンピュート）、Branching コンピュート、Read Replica コンピュート
PITR（Point-in-Time Recovery）
カスタムドメイン、IPv4 アドレス
追加プロビジョニングした Disk IOPS・スループット
Log Drain、Advanced MFA Phone

これらは「ユーザーが明示的にオプトインする予測可能な項目」のため Spend Cap の対象外とされています。裏を返せば、ノンデベロッパーがダッシュボードからうっかり PITR や追加コンピュートを有効化すると、Spend Cap オンでも課金が走るということです。安全に渡すなら、こうした add-on を有効化させない（あるいは権限を絞る）運用が前提になります。

なお実運用では、Egress やストレージよりも Compute が最大のコスト要因になるケースが多い点も覚えておくとよいでしょう。Pro / Team には $10/月のコンピュートクレジット（Micro 1 台分）が含まれますが、追加プロジェクトや上位インスタンスを使うと、Spend Cap とは無関係に固定費が積み上がります。

超過時に何が起きるか

定額側（Free または Pro + Spend Cap オン）と従量側（Pro + Spend Cap オフ / Team / Enterprise）で、超過後の流れはまったく異なります。図にすると次のようになります。

flowchart TD
    A[使用量がクォータ超過] --> B{プラン / Spend Cap}
    B -->|Free または Pro + Spend Cap オン| C[請求先メールに通知]
    C --> D[猶予期間 grace period]
    D --> E{是正したか}
    E -->|はい| F[通常運用へ]
    E -->|いいえ| G[Fair Use Policy による制限]
    G --> H[402 / 読み取り専用 / 一時停止 / 新規作成停止 など]
    B -->|Pro + Spend Cap オフ / Team / Enterprise| I[サービス継続]
    I --> J[超過分を従量課金]
    J --> K[次回 billing cycle reset 時に請求]
    L["Spend Cap 対象外の add-on（PITR・Compute など）"] --> K

定額側では、クォータを超えるとまず請求先メールアドレスに通知が届き、猶予期間（grace period）が与えられます。この間に使用量をクォータ内に戻すか上位プランへ移行すれば通常運用に戻れますが、是正しないまま放置すると Fair Use Policy に基づく制限が段階的に適用されます。制限の内容は、プロジェクトの一時停止、データベースの読み取り専用化、新規プロジェクト作成・転送の無効化、全 API リクエストへの 402 ステータス応答などです。

ここに運用上のトラップがあります。猶予期間は事実上一度限りで、一度使い切ると、その後に再び超過した際には猶予なしで即制限される仕様です。また、いったんクォータ超過で制限がかかると、使用量を下げても次の請求サイクルまで制限が解除されないのが原則で、サイクル後でも反映に最大 24 時間ほどかかる、場合によってはサポート対応が必要になる、というコミュニティ報告もあります。「定額＝無制限に使える」ではなく「定額＝超過したら止まる」である点を、渡す相手にも事前に伝えておくべきです。

従量側では通知や制限ではなく、超過分がそのまま課金されます。請求は使った瞬間に即時確定するのではなく、組織の billing cycle がリセットされるタイミングで後払いとして確定します。プラン上限の 20% 以内に近づくとメール通知が届くため、従量を許容する場合はこの通知と Usage ページ、Upcoming Invoice を定期的に確認するのが前提になります。

データベースの読み取り専用モードは別軸の注意点

課金とは別に、データベース容量だけは「課金されるかどうか」ではなく「書き込みが止まるかどうか」という挙動になりやすい項目です。これは定額・従量どちらでも起こりえます。

Free プランでは、データベースサイズ（実際の Postgres データ量）が 500 MB を超えると読み取り専用モードに入ります。重要なのは、これがディスクサイズ（Free は 1 GB）ではなく実データ量での判定だという点です。読み取り専用モードでは INSERT などの書き込みが cannot execute INSERT in a read-only transaction エラーになります。復帰は使用量がディスクサイズの 95% 未満に戻れば自動で行われます。詳細は公式の Understanding Database and Disk Size にまとまっています。

Pro プラン以上では、ディスクが割り当て容量の 90% に達すると自動的に 50% 拡張されます（例: 8 GB から 12 GB へ）。ただしこの自動リサイズは AWS EBS の制約により 24 時間のローリングウィンドウで最大 4 回までという上限があります。大量インポートなどで 24 時間以内に拡張上限に達し、なお 95% を超えると、それ以上拡張できず読み取り専用にロックされます。つまり Pro でも「課金されれば無制限に書ける」わけではなく、急激な流入では書き込みが止まりえます。大量の初期データ移行を予定しているなら、事前に十分なディスクサイズを手動でプロビジョニングしておくのが安全です。

主要な超過レート（2026 年 6 月時点）

従量課金を許容する場合に備えて、主要項目の超過レートを整理しておきます。いずれも USD 建てで、Pro / Team プランの内包枠を超えた分に適用されます。

項目	内包枠（Pro/Team）	超過レート
データベースディスクサイズ（gp3）	8 GB	$0.125/GB/月
データベースディスクサイズ（io2）	0 GB（最初のバイトから課金）	$0.195/GB/月
Egress（非キャッシュ）	250 GB	$0.09/GB
キャッシュ Egress	250 GB	$0.03/GB
ファイルストレージサイズ	100 GB	$0.0213/GB/月
MAU（月間アクティブユーザー）	100,000	$0.00325/MAU
Edge Function 呼び出し	200 万回	$2/100 万回
Realtime メッセージ	500 万件	$2.50/100 万件
Realtime ピーク同時接続	500	$10/1,000 接続
画像変換	100 枚	$5/1,000 枚

Egress は Database・Auth・Storage・Edge Functions・Realtime・Log Drains・Supavisor の全サービスの送信トラフィックを合算した「統合 Egress クォータ（Unified Egress Quota）」として扱われます。画像や動画を多く配信するメディアアプリ、リアルタイム同期を多用するチャットアプリでは、開発者が意図しないうちに 250 GB を使い切るリスクが構造的に高い項目です。ノンデベロッパーが作ったアプリでは、この Egress と MAU が最も「想定外の課金」が出やすいと考えておくべきです。

バイブコーダーに安全に渡すための構成

ここまでを踏まえ、ノンデベロッパーに Supabase の DB を渡すときの推奨構成を整理します。狙いは「予想外の従量課金を構造的に発生させないこと」です。

まず大前提として、相手に渡す組織は Free プラン、または Pro プランで Spend Cap をオンに固定します。これが定額を担保する根幹です。検証用やプロトタイプ用なら Free で十分なケースが多く、課金リスクはゼロにできます。本番でコンピュートや日次バックアップ、独自 SMTP などが必要になったら Pro に上げますが、その際も Spend Cap はオンのままにします。

次に、Spend Cap の保護対象外の add-on（PITR・追加コンピュート・カスタムドメイン・IPv4 など）を、相手が勝手に有効化できないようにします。ダッシュボードの操作権限を絞る、組織オーナーを自分が握る、課金設定は本人に触らせない、といった運用で抑えます。Spend Cap オンでもここだけは課金が走るため、最も注意すべきポイントです。

そして、相手ごと・用途ごとに組織を分けます。課金は組織単位なので、組織を分ければ一人の暴走が他に波及しません。万一 Free の組織でクォータ超過が起きても、課金は発生せず読み取り専用や一時停止で止まるだけなので、被害はその組織内のサービス停止に限定されます。

最後に、定額を選ぶ＝超過したらサービスが止まる、というトレードオフを相手と共有しておきます。可用性を最優先する本番では従量（Spend Cap オフ）が推奨されることもありますが、ノンデベロッパーに渡す前提では「止まる方が、青天井で課金されるより安全」という判断がほとんどの場合に正しいでしょう。

まとめ

要点を整理します。

Supabase で超過分を従量課金しない設定は存在する。Free プラン、または Pro プランで Spend Cap をオンにすれば料金は定額に固定される。
Spend Cap は Pro 専用のトグルで、デフォルトはオン。Team プラン以上には存在せず、超過は常に従量課金される。
Spend Cap は金額ベースの予算上限ではなく、完全ブロックか完全従量かの二択。「月いくらまで」という設定はできない。
Spend Cap オンでも、PITR・追加コンピュート・カスタムドメイン・IPv4 などの add-on は常に課金される。ノンデベロッパーには勝手に有効化させない運用が必須。
定額側では超過時に課金ではなく制限（通知→猶予期間→Fair Use Policy による一時停止・読み取り専用化）が走る。猶予期間は事実上一度限り。
データベース容量は別軸で、Free は 500 MB 超、Pro はディスク拡張の上限到達で読み取り専用になりうる。
安全に渡すなら、相手ごとに組織を分け、Free か Pro + Spend Cap オンに固定し、保護対象外 add-on を触らせないのが基本構成。

予想外の従量課金を止める設定は確かに用意されています。ただし「Spend Cap オンなら何をしても無料」ではなく、保護対象外の add-on と、超過時にサービスが止まるという挙動を理解したうえで使うことが、ノンデベロッパーに安心して DB を渡す鍵になります。

以上、Supabase の超過課金を止める設定を、バイブコーダーへの安全な DB 提供という観点から整理した、現場からお送りしました。