ドキュメント

上限と料金

無料プランは 1 人の GitHub サイト 1 つだけで上限を超えると拒否し、有料プランは請求するということ。

上限と料金

usage は、このプロジェクトが今持っているもの（テーブル、行、ユーザー、ファイルの数と、データやファイルの容量）を返します。今月の請求額と日別の使用量は get_billing が返します（オーナー、管理者、請求担当のみ）。カードと支払い履歴は、コンソールの請求画面（/billing）にしかありません。数字を人に伝えるときは、単位と基準時刻を一緒に書いてください。

無料プラン: 1 人、GitHub のサイト 1 つ、超えると拒否します

無料プランは、GitHub で登録したアカウントごとに 1 組織です。できることはこれだけです。

• 1 人（オーナー）だけで使います。invite_member は拒否されます。
• GitHub リポジトリのサイトを 1 つ、既定のアドレス（*.<zone>）にデプロイします。本番デプロイのみ、1 日 10 回までです。
• ビルドは月 30 分、転送量は月 1GB までです。超えると翌月 1 日まで止まり、請求はしません。
• 3 日間アクセスもデプロイもコンソールの利用もないサイトは一時停止します（前日にメール）。データは削除せず、resume_project か新しいデプロイですぐに戻ります。
• 商用目的では使えません。

データベースとその上のすべて（テーブル、SQL、ログイン、ファイル、リアルタイム、キュー、Vault、予約ジョブ、DB Webhook、ブランチ、バックアップ）、関数、サーバー、 AI ゲートウェイ、エッジ設定・KV・フラグ・ミドルウェア、分析、ログ転送、独自ドメインは Pro です。無料プロジェクトでこれらのツールを呼ぶと、 402 と「無料プランでは使えない機能です。Pro にアップグレードするとすぐに使えます。」で拒否されます。 プロジェクト API も同じ理由で plan_required（402）を返します。

このときすべきことは再試行ではありません。コンソールのお支払い画面（/billing）で Pro にアップグレードするか、利用者に尋ねてください。 Pro への切り替えは、人が料金・請求開始日・支払い方法・解約方法を確認して同意した場合にのみ行われます。ツールでは切り替えられず、自動で切り替わることもありません。 get_plan の free に現在適用される上限があります。

Pro プラン: 月額 ₩62,000（付加価値税込み）、超えた分を請求

海外決済（Lemon Squeezy）は月額 $42 で、税金は決済時に別途加算されます。 最初のプロジェクト、専用 2GB サーバー 1 台、メンバー 3 人が料金に含まれます。プロジェクトを増やすと 1 つにつき月 $16（専用 DB マシン 1GB）、メンバーは 1 人につき月 $10 かかります。自分のサーバーを借りたプロジェクトはそのサーバーのサイズ料金だけです。含まれる量は組織全体の量です。 拒否せず、請求します。含まれる量と超過単価:

データベースの単価には、毎日のバックアップと7日間のポイントインタイム復元用コピーの原価が含まれています。 AI エージェントのトークンは既定のモデル（deepseek-flash）を基準に数えます。運営者がより高価なモデルを使うと、その費用の分だけ多く数えます（v4-pro は4倍）。 支出上限がオンなら含まれる量で止まり、オフなら超えた分が請求されます。 サーバーメモリ 186GB・時間は、512MB のサーバー1つを月の半分ほど動かせる量です。関数の実行・予約ジョブの実行・サーバーメモリの含まれる量は2026年10月に減りました（40万GB·秒 → 10万、100万回 → 20万、372GB・時間 → 186）。それ以前から Pro の組織は、お知らせメールに書かれた請求期間まで以前の含まれる量を使えます。get_billing の included が今適用される値です。

設計するときに知っておくこと

呼び出し回数は無料で、出ていくバイトが高いのです。ソウルから出ていくトラフィックは Google の料金の中でも最も高い部類で、その価格がそのままここに反映されています。

そのため、費用を減らす方法はリクエストを減らすことではなく、レスポンスを小さくすることです。

• select= で必要な列だけを選んでください。大きなテーブルを select=* で読むことが、ほとんどの請求書の原因です。
• 画像や動画のような大きなファイルには、長いキャッシュヘッダーを付けてください。同じファイルを2回送ると、2回分として計算されます。
• 一覧には limit を付けてください。

手を入れる前に usage を1回呼び出し、どの指標が実際に大きいかを確かめるほうが、 推測で最適化するより常に良い結果になります。