個人開発者のための Supabase と Cloudflare

個人でサービスを作るとき、バックエンドに何を使うか。Supabase と Cloudflare が候補に挙がることが多いので、実際の数値で整理します。

この記事の数値は2026年8月時点の公式情報です。 この手の上限は頻繁に変わるので、実際に契約する前には必ず公式を確認してください。出典は最後にまとめています。

まず、この2つは同じ層の製品ではない

比較の前にここを押さえないと、話が噛み合いません。

Supabase は BaaS です。データベース、認証、ストレージ、リアルタイム通信が最初から1つにまとまっています。契約すればその日から全部使えます。

Cloudflare は部品の集合です。処理を動かす Workers、SQLのデータベース D1、キーバリューの KV、ファイル置き場の R2。必要なものを自分で選んで組み合わせます。

つまり「Supabase 対 Cloudflare」ではなく、「1つにまとまったもの」対「自分で組むもの」の比較になります。

最後の2行が、この記事の結論にほぼ直結します。

無料枠の実数

まず無料でどこまでやれるか。

有料に上げたときはこうなります。

決定的な差は3つ

数字を眺めるより、判断を変える差だけ拾った方が早いです。

1. 認証があるかないか

Supabase には認証が付いています。無料で月間5万ユーザーまで。

Googleログインもメール認証も、設定で入ります。さらに「本人のデータは本人だけが読める」というアクセス制御を、コードではなくデータベースの設定として書けます。

Cloudflare には、これに当たるものがありません。 認証系の製品（Access や Managed OAuth）はありますが、あれは社内アプリを守るためのゼロトラスト用途で、一般ユーザーがサインアップして使うアプリのための仕組みではありません。

つまり Cloudflare で会員制のアプリを作るなら、認証は自分で組むか、外部のサービスを足すことになります。 パスワードを安全に保管する仕組みを自作するのは、本来とても難しく、間違えると危険な領域です。

ここが最大の差だと思っています。

2. 無料プランが止まるかどうか

Supabase の無料プランは、1週間使わないとプロジェクトが一時停止します。

個人開発でこれは効きます。作って公開して、しばらく触らずにいると止まる。誰かが見に来たときに動いていない。趣味の延長で置いておきたいものには向きません。

Cloudflare の無料プランは止まりません。置いておけます。

3. 転送量（egress）が無料かどうか

R2 は転送量が無料です。 これは画像やファイルを配信するサービスでは決定的です。

Supabase の無料プランは月5GB。画像を扱うサイトだと、意外と早く到達します。有料プランでも250GBを超えれば $0.09/GB。

自社のECサイトを作り直したとき Cloudflare を選んだのは、まさにここでした。ECは画像が主役なので、転送量に課金されない構造が効きます。

アプリのバックエンドに使うなら

ログインがあって、ユーザーごとにデータを持つなら Supabase です。 迷う必要はないと思います。

理由は上の1つ目です。認証を自分で組まなくていい。しかも「本人のデータは本人だけ」を設定で書ける。この2つを Cloudflare で用意すると、作る量が一気に増えます。

無料の月間5万ユーザーは、個人開発の規模ならまず埋まりません。

注意点は1週間で止まることです。人に使わせるアプリなら、無料のままでは置けません。$25の Pro に上げるか、定期的に触るかのどちらかです。

Webサービスに使うなら

公開コンテンツが主役で、ログインが要らないなら Cloudflare です。

サイト、メディア、ブログ、商品を並べる店。この形だと Supabase の最大の強みである認証が効きません。逆に、転送量が無料で、止まらず、$5で広い範囲が使える Cloudflare の性質がそのまま利点になります。

いま読んでいるこのサイトも、記事の本文と画像を R2 に置いています。認証は使っていません。決済は Stripe に任せているので、ユーザー管理そのものが要らない構造です。

「ログインが必要か」を最初に決めると、選択はほぼ自動的に決まります。

両方使うという手もある

排他ではありません。認証とデータベースは Supabase、画像の配信は R2 という組み合わせは現実的です。

転送量の課金は画像で膨らむので、そこだけ R2 に逃がす。認証は自作しない。それぞれの得意な部分だけ借りる形です。

教科書で Supabase を勧めている理由

この教科書では、データと認証に Supabase を使うと書いています。この記事と矛盾しているように見えるかもしれないので、立場を書いておきます。

最初の1つを完成させるなら、部品が少ない方が完成する確率が高い。 これが理由です。認証もデータベースもストレージも1つにまとまっていれば、覚えることが減り、繋ぐ作業も減ります。0から1を目指す段階では、それがいちばん効きます。

この記事は、その先の話です。事業が回り始めて、転送量や固定費が気になり始めてから考えればいい。最初から最適化しようとして完成しないのが、いちばん損です。

選ぶときに気をつけたいこと

外部のサービスを組み込むときは、初期段階では逃げやすい形にしておくのを勧めます。

サービスに深く依存する書き方をすると、あとで移りたくなったときに動けません。データの出し入れを1箇所に集めておく、独自の機能に寄りかかりすぎない。それだけで、後から選び直せる余地が残ります。

収益が出てから、実際の使用量を見て固めていく。この順番が安全です。

出典

数値はすべて2026年8月時点の公式ページから引いています。

• Supabase Pricing
• Cloudflare Workers Pricing
• Cloudflare D1 Pricing
• Cloudflare R2 Pricing