Supabaseの無料枠制限：個人開発でセルフホスト移行を検討すべき境界線

データベース容量が500MBに達すると、データベースは読み取り専用になる。7日間、ユーザー操作やAPIアクセスなどのアクティビティがなければ、プロジェクトは自動的に一時停止される。無料プランで維持できるアクティブなプロジェクトも、組織あたり2個までである。

この仕様は、検証用アプリでは問題になりにくい。しかし、ユーザーが存在するサービスでは障害要因になる。個人開発でSupabaseを使う場合、無料枠を使い続けられるかではなく、どの制限が最初にボトルネックになるかを見極める必要がある。

Supabase無料プランの制限は容量だけではない

無料プランの制限は、データベース容量だけを見て判断すると誤る。認証ユーザー、ファイルストレージ、帯域幅、プロジェクト数、非アクティブ時の停止が同時に存在するためである。

主な上限は次の通りである。

個人開発のサービスで最初に到達しやすいのは、必ずしもデータベース容量ではない。画像、動画、ログ、エクスポートファイルをSupabaseのストレージに保存している場合、ファイル容量や帯域幅が先に問題になる可能性がある。

逆に、テキスト中心のサービスでは、データベースの500MBが長期間残ることもある。投稿本文、ユーザー設定、課金情報、イベントログを同じデータベースに保存する場合は、ログの蓄積が容量を押し上げる。

500MBは「小さいデータベース」という意味ではない

500MBという数字だけを見ると、個人開発には十分に見える。実際、ユーザー数が少なく、画像を外部ストレージに置き、不要なログを削除しているサービスであれば、初期段階では問題にならない。

ただし、データベース容量はテーブルのデータだけで消費されるわけではない。インデックス、不要な履歴、セッション関連のデータ、監査ログ、ジョブの実行履歴なども蓄積する。

設計時点では小さな補助テーブルでも、運用開始後に毎回のAPIリクエストで行が追加されると、容量の増加速度は変わる。特に次のような設計は注意が必要である。

• APIアクセスのたびにイベントログを保存する
• ユーザーごとの操作履歴を無期限に保持する
• 外部サービスの同期結果を全件保存する
• 失敗したジョブやWebhookの履歴を削除しない
• 本文の更新履歴をすべてデータベースに残す
• 検索用のデータと表示用のデータを重複して保存する

この構成では、サービスのユーザー数が少なくても容量は増える。DBのレコード数ではなく、1日あたりの書き込み量と保持期間で計算する必要がある。

Supabase無料枠の判断で見るべきなのは、現在の容量ではない。容量の増加速度と、制限到達時の復旧手順である。

月間アクティブユーザー50,000人は本当の境界線か

無料プランの認証機能には、月間アクティブユーザー50,000人の上限がある。個人開発の初期サービスにとって、この数字は大きい。

ただし、MAUは登録ユーザー数と同じではない。登録済みユーザーが50,000人いても、当月に認証やサービス利用がなければ、月間アクティブユーザーの扱いは異なる。一方で、短期間に多くのユーザーがログインするサービスでは、登録者数が少なくてもMAUは増える。

ここで問題になるのは、ユーザー数の増加そのものより、認証をサービスの中心に置いているかである。ユーザー登録、パスワードリセット、メール認証、ソーシャルログインをSupabase Authに依存している場合、認証機能の制限はアプリケーション全体の停止につながる。

認証だけを別のサービスに分離する設計も可能である。しかし、その場合はユーザーIDの対応、セッション管理、権限同期が必要になる。無料枠の制限を回避するためだけに認証基盤を分割すると、依存関係が増える。個人開発では、容量制限を避ける代わりに保守コストが増えるケースがある。

制限に達したとき、サービスはどう止まるのか

個人開発者が最も誤解しやすいのが、無料枠超過時の挙動である。

クレジットカードを登録していない無料プランでは、制限を超えた分が自動的に請求されてサービスが継続するわけではない。データベースの読み取り専用化やプロジェクトの一時停止など、機能制限が発生する。

データベース容量500MB到達時の読み取り専用化

データベースが読み取り専用になると、取得処理は動いても、登録や更新が失敗する可能性がある。

この状態は、画面表示だけを見ると発見が遅れる。トップページや既存データの表示は動くため、サービスが稼働しているように見えるからである。実際には、次の処理が失敗する。

• 新規ユーザー登録後のプロフィール作成
• 投稿の新規作成
• 既存データの更新
• 決済状態や契約状態の更新
• Webhookによるステータス変更
• バッチ処理による集計結果の保存
• パスワードリセットなどに伴う認証関連の更新

このタイプの障害は、HTTPステータスやアプリケーションログを確認しないと原因が分かりにくい。フロントエンド側では、単に保存ボタンが反応しない、登録処理が完了しない、といった症状になる。

したがって、Supabaseを本番利用する場合は、書き込み失敗を単なる入力エラーとして処理してはいけない。データベース接続、権限、容量、制約違反を切り分けられるログが必要である。

LaravelをAPI層に使う場合であれば、例外を一律に500番台へ変換するだけでは不十分である。データベースの書き込み失敗を記録し、管理者へ通知する経路を用意するべきである。ユーザーには一般的なエラーメッセージを返しつつ、内部ログではSQLSTATE、操作対象、リクエストIDを保持する。

7日間の非アクティブによる自動一時停止

無料プランでは、7日間にユーザー操作やAPIアクセスなどのアクティビティがない場合、プロジェクトが自動的に一時停止される。

個人開発では、次のようなプロジェクトが対象になりやすい。

• 開発途中で公開を止めたアプリ
• 週末だけ更新する検証環境
• デモ用に作成したプロジェクト
• 既存サービスの旧バージョン
• 記事執筆や学習用に作った環境

一時停止中はAPIリクエストが失敗する。ダッシュボードなどから手動で再開する必要がある。プロジェクトが削除されるわけではないが、停止を前提にした運用では、初回アクセス時に障害が発生する。

再開には管理者の操作が必要である。深夜や休日にアクセスが発生した場合、すぐに復旧できない可能性がある。サービスの利用者がいるなら、無料プランの自動停止は単なるコスト削減機能ではなく、可用性の制約である。

一時停止されたプロジェクトは、Supabase Studioから1年間復元できるとされている。これは復旧可能期間であり、常時稼働を保証する期間ではない。停止状態を放置したまま、バックアップの代わりに使う設計は危険である。

定期的なPingは本番運用の設計にならない

非アクティブによる一時停止を避けるため、外部の定期実行サービスやGitHub ActionsからAPIへアクセスする方法が紹介されることがある。

ただし、これは公式に推奨された本番運用手法として扱うべきではない。仕様変更によって判定条件が変わる可能性がある。利用規約やサービス仕様との整合性も確認が必要である。

定期アクセスを設定したとしても、次の問題は残る。

• アクセス元の認証情報を安全に保管する必要がある
• 定期実行サービス自体の障害に依存する
• APIの応答だけでは実際のデータベース状態を確認できない
• プロジェクト停止以外の容量制限は解決しない
• 停止回避を保証できない

無料枠の自動停止を回避するために監視や定期実行を追加するなら、その時点で運用対象が増えている。手間を削減するための無料枠が、別の保守タスクを生む構造である。

Proプランへの変更とセルフホスト移行を比較する

無料プランの次に選択肢になるのは、Proプランへの変更である。Proプランは1プロジェクトあたり月額25ドルから開始する。Spend Capを設定しない場合、超過分は従量課金となる。無制限の請求を防ぐため、Spend Capを設定して上限超過時に停止させる運用も可能である。

セルフホストでは、Supabaseが公式リポジトリで提供しているDockerおよびDocker Composeの設定を利用し、自分でVPSなどへ環境を構築する。プラットフォーム側の無料枠にある容量やプロジェクト数の制限は受けにくくなる。

ただし、制限が消えるわけではない。制限の場所がSupabaseからVPSへ移るだけである。

Proプランは、運用作業を減らすための費用である。セルフホストは、サービスの制御範囲を広げる代わりに、障害対応と保守を引き受ける構成である。

Proプランが合理的なケース

次の条件では、セルフホストよりProプランへの変更が合理的である。

1. サービスを止めたくない

無料プランの一時停止や容量到達が業務上の問題になるなら、まず有料プランを検討するべきである。インフラの移行は、開発機能を増やさない。移行中はむしろリリース速度が落ちる。

2. 開発者がインフラ運用を担当できない

セルフホストでは、障害発生時に原因を調査する必要がある。Dockerコンテナ、PostgreSQL、APIゲートウェイ、認証、ストレージ、ネットワークのどこで問題が発生したかを切り分けなければならない。

3. 月額25ドルが運用工数より安い

費用比較では、VPSの金額だけを見てはいけない。バックアップの確認、セキュリティ更新、ログの整理、障害対応、データ移行の時間を含める必要がある。

4. Supabaseのマネージド機能に依存している

認証、ストレージ、リアルタイム通信、管理画面などを一体で使っている場合、セルフホスト移行は単純なPostgreSQLのコピーでは終わらない。各機能の設定差分を確認する必要がある。

5. 収益化やユーザーサポートを優先したい

サービスに課金ユーザーがいる場合、インフラ費用は売上を支えるための固定費になる。自前運用で数ドルを削減するより、障害対応の時間を減らす方が合理的な場合が多い。

セルフホスト移行が合理的なケース

一方で、セルフホストが有効なケースもある。

• データベースやストレージの保持場所を自分で管理したい
• 複数の検証環境を長期間維持したい
• Supabaseの無料プランにあるプロジェクト数制限が運用の障害になっている
• DockerとPostgreSQLの保守経験がある
• VPSの監視、バックアップ、復旧を自分で設計できる
• トラフィックとデータ量の増加を自分で予測できる
• ベンダーの料金体系に依存したくない

ただし、セルフホストを選ぶ理由は「無料だから」では弱い。Supabaseの利用料金が発生しなくても、VPS、ディスク、バックアップ、監視、メール配信、ドメイン、TLS証明書などの費用は別に発生する。

さらに、コンピュートリソースの上限もある。VPSのメモリ不足、CPU不足、ディスクI/Oの遅延が発生すれば、Supabaseの無料枠を超えなくてもサービスは遅くなる。

セルフホストは無料化ではない。運用の責任範囲を、サービス提供者から自分の環境へ移す選択である。

DockerによるSupabaseセルフホストの現実的な設計

Supabaseのセルフホストでは、公式が提供するDocker設定を利用できる。これにより、各コンポーネントを個別にインストールするより、初期構築の再現性を確保しやすい。

しかし、Docker Composeを起動できることと、本番運用できることは別である。

最初に分離すべき環境

個人開発では、開発環境、ステージング環境、本番環境を同じVPSに置きたくなる。費用を抑えられるからである。

この構成には、次のリスクがある。

• 開発用の設定変更が本番へ影響する
• コンテナ再作成時に別環境も停止する
• ディスク使用量が共有される
• ログの急増で本番データベースが影響を受ける
• バックアップ対象と復元対象の切り分けが難しくなる

最初からすべてを分離する必要はない。ただし、データベースのボリューム、環境変数、公開ポート、バックアップ先は区別するべきである。

本番用のデータを開発環境へ直接コピーする運用も避ける必要がある。認証情報や個人情報が含まれる場合、データの複製自体がリスクになる。検証用データは匿名化するか、必要な最小限だけを生成する構成が安全である。

データベースのバックアップは別の保存先へ置く

同じVPSの別ディレクトリへバックアップを保存しても、ディスク故障やVPS障害には対応できない。バックアップは、少なくとも本番データベースと異なる障害ドメインへ置く必要がある。

バックアップ設計では、次の項目を決める。

• 何時間分のデータ損失を許容するか
• 何日前まで復元できる必要があるか
• バックアップをどの頻度で取得するか
• 取得失敗をどのように検知するか
• 復元テストをどの頻度で行うか
• バックアップデータを暗号化するか
• 保存期間を過ぎた世代をどう削除するか

バックアップファイルが存在するだけでは不十分である。復元できることを確認して初めて、バックアップとして機能する。

Supabaseをセルフホストする場合、PostgreSQLのバックアップだけでなく、認証設定、ストレージのメタデータ、保存ファイル、環境変数、各種キーの扱いも確認対象になる。データベースだけ復元できても、ストレージや認証設定が一致しなければ、アプリケーションは正常に戻らない。

TLS、メール、ストレージは別のボトルネックになる

セルフホスト移行では、データベースだけを見ていると設計が止まる。実際のサービスには、HTTPS、メール送信、ファイル保存、ログ収集が必要になる。

TLS証明書は、更新処理が止まるとブラウザからアクセスできなくなる。メール認証やパスワードリセットを使うなら、SMTP設定と送信元ドメインの管理が必要である。ファイルストレージをVPSのローカルディスクに置く場合、ディスク故障や容量不足がアプリケーション停止に直結する。

無料プランからセルフホストへ移行する際は、次の依存関係を洗い出すべきである。

• Supabaseのデータベースへ接続するアプリケーション
• Supabase Authで発行されるユーザーID
• Row Level Securityのポリシー
• Supabase Storageに保存されたファイル
• 署名付きURLを利用する処理
• Edge FunctionsやWebhook
• Realtimeを利用する画面
• 管理画面から変更した設定
• メール認証やパスワードリセットの送信経路
• 外部サービスから接続されるAPIキー

移行対象がPostgreSQLだけなら、作業量は比較的限定される。しかし、Supabaseのサービス群を使い込んでいるほど、移行はインフラ変更ではなくアプリケーション再設計になる。

Supabase PostgreSQLを移行するときの注意点

Supabaseの無料枠からセルフホストへ移行する場合、最初に確認するのはデータベースの互換性である。一般的なPostgreSQLのテーブル、インデックス、制約、関数を使っているだけなら、データの移行は設計しやすい。

一方で、Supabase固有の機能や権限モデルに依存している場合は、確認範囲が広がる。

Row Level Securityの移行

Supabaseでは、データベース側のRow Level Securityを使って、ユーザーごとのアクセス制御を行える。これはアプリケーション側のif文だけで権限を制御するより、データベース層で制約を強制できる点が強い。

ただし、移行先でも次の条件が一致している必要がある。

• 認証済みユーザーを示す情報の渡し方
• データベース接続ユーザー
• セッション情報の設定方法
• ポリシーが参照するユーザー識別子
• 管理者権限を持つ接続の扱い
• サービスロール相当のキーの保護

接続方式が変わると、ポリシーが存在していても期待した権限制御にならない可能性がある。移行後は、ユーザー本人、別ユーザー、未認証ユーザー、管理者の4パターン程度で読み取りと書き込みを確認する必要がある。

Authのユーザー移行

認証ユーザーの移行は、テーブルのダンプと同じ感覚では扱えない。パスワードハッシュ、メール確認状態、プロバイダー情報、ユーザーIDの対応関係が関係するからである。

ユーザーIDを変更すると、投稿、契約、決済、アクセスログなど、ユーザーIDを外部キーとして持つすべてのテーブルに影響する。

そのため、移行前に次の方針を決めるべきである。

1. ユーザーIDを維持したまま移行する

2. 新しい認証基盤へ移行し、ユーザーIDの対応表を持つ

3. 初回ログイン時にユーザー情報を再連携する

4. 一部ユーザーだけ先行移行する

5. 認証基盤はSupabaseに残し、データベースだけを移行する

どの方式でも、パスワードを平文で扱うことはできない。パスワード再設定を促す方式を採用する場合は、移行後のユーザー体験とメール送信経路を設計する必要がある。

ストレージの移行

ファイルストレージを使っている場合、データベースの移行だけでは不完全である。ファイル本体と、ファイルのメタデータを別々に移す必要がある。

特に、アプリケーションが署名付きURLを前提にしている場合、移行先のバケット構成、公開範囲、URL生成方式が変わる可能性がある。既存URLをそのまま維持できるかも確認対象である。

ファイルをVPSへ置く場合、バックアップサイズが急増する。画像を保存するサービスなら、ファイルストレージとデータベースを同じディスクに置く設計は避けた方がよい。容量不足が発生した際、データベースの書き込みまで止まるからである。

移行を判断するための運用指標

無料プランからProプラン、またはセルフホストへ移行するタイミングは、ユーザー数だけでは判断できない。確認すべきなのは、制限までの距離と、停止した場合の影響である。

容量の増加速度を見る

データベース容量は、現在値ではなく増加速度を見る。例えば、数か月間の使用量を記録し、どのテーブルが増えているかを確認する。

見るべき項目は次の通りである。

• データベース全体の使用量
• テーブルごとの使用量
• インデックスの使用量
• 1日あたりの増加量
• ログテーブルの増加量
• 削除済みデータや不要データの残存量
• ストレージの使用量
• 帯域幅の消費量

500MBまでの残量があっても、短期間で到達するなら対策が必要である。逆に、数年単位で到達しない見込みなら、容量だけを理由にセルフホストへ移行する必要はない。

書き込み処理の重要度を見る

同じ容量でも、書き込み処理の重要度によって危険度は異なる。

読み取り中心の公開サイトであれば、データベースが一時的に読み取り専用になっても、既存コンテンツの表示は続く可能性がある。しかし、予約、決済、ユーザー投稿、在庫、契約管理を扱うサービスでは、書き込み停止が即時に業務停止となる。

判断時には、次のように処理を分類するとよい。

この分類で書き込み停止の影響が大きいなら、無料プランに依存する期間を短くするべきである。

一時停止の許容度を見る

サービスが7日間アクセスされないことを許容できるかも重要である。

個人用ツールや学習用アプリなら、再開操作が必要でも問題にならない。しかし、検索流入を受けるWebサービス、通知を送るアプリ、定期処理を実行するサービスでは、アクセスが少ない期間でも停止が問題になる。

特に、バックグラウンド処理が存在する場合は注意が必要である。ユーザーが画面を開かなくても、外部APIからのWebhook、定期ジョブ、メール送信、集計処理が動くことがある。アプリへのアクセスが少ないから安全とは限らない。

プロジェクト数を先に管理する

無料プランでは、組織あたりアクティブなプロジェクトを2個まで維持できる。個人開発では、開発用と本番用だけで上限に達する。

ここへステージング環境、別サービス、デモ環境を追加すると、プロジェクト数が問題になる。不要なプロジェクトを削除すればよいという判断もあるが、後から参照したいデータや設定が残っている場合、削除は慎重に行う必要がある。

複数サービスを継続的に開発するなら、次のいずれかを早めに決めるべきである。

• サービスごとにプロジェクトを分ける
• 1プロジェクト内で環境を論理分離する
• Proプランでプロジェクト数を増やす
• VPS上でDocker Compose構成を分離する
• 検証環境を短期間だけ作成して破棄する

ここで重要なのは、環境分離と障害分離を混同しないことである。同じプロジェクト内でデータベースだけを分けても、プロジェクト全体の停止や設定変更の影響は共有する。

個人開発で現実的な移行戦略

最初からセルフホストを選ぶ必要はない。個人開発では、サービスの段階に応じて依存範囲を変える方が合理的である。

段階1：無料プランで検証する

アイデア検証や開発初期では、無料プランの制限を許容できる。ここで確認するのは、機能の成立性である。

ただし、将来の移行を考えるなら、Supabase固有機能への依存を記録しておく。テーブル定義、RLSポリシー、認証設定、ストレージ構成を管理画面だけに残してはいけない。

データベースのスキーマ変更は、再実行可能なマイグレーションとして管理する。Laravelを利用する場合も、アプリケーションのマイグレーションとSupabase側の差分が一致しているか確認する必要がある。

段階2：公開後は使用量を監視する

ユーザーが使い始めたら、毎月の使用量を確認する。確認対象は、データベース、MAU、ファイルストレージ、帯域幅、プロジェクト数である。

この段階では、制限直前まで使い切るのではなく、余裕を持って判断する。容量が上限に近づいてから移行を開始すると、データ整理と移行作業を同時に行うことになる。

特に、課金やユーザー投稿を扱うサービスでは、無料枠の限界を待つべきではない。障害が発生してから移行を始めると、移行作業そのものが緊急対応になる。

段階3：Proプランで運用を安定させる

ユーザーが存在し、セルフホストの準備ができていないなら、Proプランへ変更する。これは最終決定ではない。移行時間を買う判断である。

Spend Capを設定すれば、予期しない従量課金の範囲を制御できる。ただし、上限超過時に停止する設定は、可用性とのトレードオフになる。請求を抑える代わりに、サービスが止まる可能性を受け入れる構成だからである。

費用上限とサービス継続のどちらを優先するかを決め、監視通知と復旧手順を用意する必要がある。

段階4：セルフホストへ移行する

セルフホストへ移行するなら、停止時間を先に定義する。完全無停止を目指すと、構成が複雑になる。個人開発では、メンテナンス時間を明示して一括移行する方が安全な場合もある。

基本的な流れは次の通りである。

1. Supabase固有機能とデータ構造を棚卸しする

2. Docker環境を別のVPSへ構築する

3. データベースの移行手順を検証する

4. Auth、ストレージ、RLSの動作を確認する

5. ステージング環境でアプリケーションを接続する

6. バックアップと復元を実行して確認する

7. 本番データの最終同期を行う

8. 接続先と環境変数を切り替える

9. 書き込み、認証、ファイル保存、Webhookを確認する

10. 旧環境をすぐに削除せず、一定期間保持する

旧環境を即座に削除してはいけない。移行直後に発生する不具合の比較対象がなくなるからである。DNSや環境変数の切り替え後も、旧環境を復旧用として保持する方が安全である。

結論：移行の境界線は「無料か有料か」ではない

Supabase無料枠の制限は、個人開発の初期には合理的である。DB容量500MB、MAU50,000人、ストレージ1GB、帯域幅5GBという上限は、検証や小規模サービスには使える範囲である。

ただし、無料プランでは制限到達時の挙動が明確である。データベースは読み取り専用になる。プロジェクトは7日間の非アクティブで一時停止される。アクティブなプロジェクトは2個までである。無料枠を超えた後も、自動課金で無条件に動き続けるわけではない。

判断基準は次の通りである。

• 書き込み停止がサービス停止に直結するなら、無料プランを本番の前提にしない
• 7日間の非アクティブ停止を許容できないなら、Proプランを検討する
• 月額25ドルが運用工数より安いなら、まずProプランへ変更する
• Docker、PostgreSQL、バックアップを管理できるなら、セルフホストを選択肢にする
• Supabase AuthやStorageへの依存が強い場合、移行工数を先に見積もる
• セルフホストを無料化と考えず、VPSと保守の費用を含めて比較する
• 制限到達後ではなく、到達前に移行手順を検証する
• バックアップは取得だけでなく、復元まで確認する

個人開発における最適解は、常にセルフホストではない。機能開発とユーザー対応を優先する時期はProプランが適している。運用環境を自分で制御し、VPSとDockerの保守を引き受けられる段階では、セルフホストの価値が出る。

無料枠の限界は、500MBや7日間という数字だけでは決まらない。サービスが停止したときに、誰が、何分で、どの手順で復旧できるかで決まる。そこまで設計できていない状態でのセルフホスト移行は、コスト削減ではなく、障害対応の内製化である。