Supabase

商用利用は全プランで可能。制約はリソース側にある

「Supabase 商用利用」で調べている方への結論を先に書きます。全プランで商用利用が認められています。 Vercel Hobby のような「無料プランは非商用限定」という規約上の制限はありません。無料枠のまま収益化しても規約違反にはなりません。

ただし無料枠を本番で使うことは推奨できません。 理由は規約ではなく、次の一時停止ポリシーです。

7日間アクセスがないとプロジェクトが止まる

無料プロジェクトは7日間アクティビティがないと自動的に一時停止されます。 復帰は手動操作です。

これが刺さるのは、アクセスがまばらだが止まってはいけない用途です。

• クライアントに見せるデモ環境
• 社内ツールで、週明けにしか使われないもの
• 公開したまま放置しがちな小規模サービス
• Webhook の受け口

止まってもエラー通知は来ません。 ユーザーからの報告で初めて気付くことになります。監視を入れるか、Pro プランに移行するかの二択です。Pro 組織のプロジェクトは一時停止されません。

なお無料枠で同時にアクティブにできるのは 2プロジェクトまでです。一時停止中のプロジェクトはこの数に数えられないため、停止済みプロジェクトはいくつでも保持できます。

無料枠の実際の容量

• データベース: 500MB（共有CPU・メモリ500MB）
• エグレス: 5GB（キャッシュ分も別途5GB）
• ファイルストレージ: 1GB

500MB は検証には十分ですが、ユーザー生成コンテンツを持つサービスでは早く到達します。

独自ドメインは Pro でも追加課金

見落とされやすい点です。独自ドメインは無料プランでは使えません。 Pro 以上で、しかも1ドメインあたり月10ドルの有料アドオンとして提供されます。「Pro にすれば使える」ではなく「Pro にしたうえで別料金」です。

ただし Supabase は BaaS であってホスティングが主目的ではありません。フロントエンドを Vercel や Cloudflare Pages に置く構成なら、この制約はほぼ無関係になります。

最大の利点は「やめられること」

技術的な優位として語られがちなのは Postgres である点ですが、実務上いちばん効くのはロックインの弱さです。

中身は素の Postgres なので、いざとなれば pg_dump で吸い出して他のマネージド Postgres（RDS、Cloud SQL、Neon など）に移せます。Supabase をやめても Postgres の資産は残ります。 Firestore のような独自データモデルでは、エクスポートできても移行先で同じ形のまま動くものがなく、実質的にアプリの書き直しになります。

加えて Supabase 自体が OSS で、セルフホストも可能です。

Row Level Security は強力だが、設定ミスが静かに刺さる

Supabase の認可は Postgres の RLS（行レベルセキュリティ）で組みます。強力な仕組みですが、ポリシーが緩いことはエラーとして現れません。 動作は正常なまま、他人のデータが見えている状態になります。

RLS を有効にし忘れたテーブルは、anon キーで全件読める状態になり得ます。本番公開前に、認証していないクライアントから全テーブルを叩いて何が返るかを実際に確認してください。 これは設定レビューではなく、実行して確かめるべき項目です。

定期実行

Cron は Postgres の pg_cron 拡張で実現します。外部のスケジューラを用意せずにデータベース側で完結できるのは利点ですが、無料枠では7日で止まるため、定期実行を無料枠に置くこと自体が成立しません。