Pockit
Back

2026年版 Supabase vs Firebase：本番環境で両方使った上での本音比較

2026年にSaaS、モバイルアプリ、サイドプロジェクトを作っているなら、いずれ同じ分岐点にたどり着きます。SupabaseかFirebaseか？

ネット上には表面的な比較記事があふれています。「SupabaseはオープンソースのFirebase！」「Firebaseの方がリアルタイムは上！」「SupabaseはただのPostgresでしょ！」こうした一行コメントは役に立たないどころか、積極的にミスリードします。現実ははるかに複雑で、間違った選択は数ヶ月の移行作業や予想外の請求につながりかねません。

このガイドは違います。両方のプラットフォームを本番環境で使ってきました。おもちゃのプロジェクトではなく、実際のユーザーと実際の請求書がある本物のアプリケーションです。本当に重要な軸すべてで比較します：データベースアーキテクチャ、認証、リアルタイム、ファイルストレージ、Edge Functions、スケール時の料金、ベンダーロックイン、開発体験。

スポンサーなし。アフィリエイトリンクなし。各プラットフォームが本当に優れている点と、痛みを伴う点を率直に分析します。

根本的な違い：SQL vs NoSQL

何よりも先に理解しておくべきことがあります。データベースの選択がすべてを決めます。 機能比較ではなく、世界観の違いです。

FirebaseはFirestoreの上に構築されています。サーバーレスのNoSQLドキュメントデータベースで、データをJSON風のネストされたドキュメントとしてコレクションに格納します。JOINなし、外部キーなし、スキーマ強制なし。データを読む方法に合わせてモデリングする発想です。

SupabaseはPostgreSQLの上に構築されています。世界で最も人気のあるオープンソースリレーショナルデータベースです。テーブル、カラム、外部キー、JOIN、制約、ビュー、ストアドプロシージャなど、リレーショナルモデルのすべてが揃っています。データの関係性に基づいてモデリングし、必要な形でクエリする発想です。

この一つの違いが、あらゆる面に波及します：

項目Firebase (Firestore)Supabase (PostgreSQL)
データモデルドキュメント & コレクションテーブル & リレーション
クエリ言語Firestore SDKメソッドSQL（+ SDKヘルパー）
JOIN非対応（非正規化で対処）ネイティブ対応
スキーマ強制なし（スキーマレス）完全対応（マイグレーション）
集計関数限定的（count, sum, avg）SQL集計が完全に使える
全文検索組み込みなし組み込み（tsvector）
トランザクションマルチドキュメント、制限あり完全なACID
データ整合性アプリレベルで担保DBレベルの制約

なぜ思っている以上に重要か： データがリレーショナルな場合（ユーザー→注文→商品→レビュー）、Firestoreでは非正規化を強いられます。JOINがないため、ドキュメント間でデータを複製することになります。ユーザー名を変更するときが問題です。そのデータがコピーされたすべての場所を追跡して更新する必要があります。Postgresなら1行更新するだけです。

逆に、データが階層的な場合（チャットメッセージ、ソーシャルフィード、IoTセンサーデータ）、Firestoreのドキュメントモデルの方が素直にシンプルになることがあります。

2026年の新展開：Firebase Data Connect。 GoogleがFirebase Data Connectをリリースしました（2025年4月GA）。Cloud SQLを通じてPostgreSQLをFirebaseエコシステムに統合するものです。NoSQLだけでは不十分だったことの事実上の認めです。Firestoreを置き換えるものではありませんが、Firebaseに常に不足していたリレーショナルのギャップを埋めてくれます。

認証：どちらも優秀、微妙な違いあり

認証は両プラットフォームとも本当によくできています。ただし細部で差が出ます。

Firebase Auth

Firebase Authは成熟していて、実戦で鍛えられています：

// Firebase Auth — ソーシャルログイン
import { getAuth, signInWithPopup, GoogleAuthProvider } from 'firebase/auth';

const auth = getAuth();
const provider = new GoogleAuthProvider();

const result = await signInWithPopup(auth, provider);
const user = result.user;
// user.uid, user.email, user.displayName — すぐ使える

強み：

  • 20以上の認証プロバイダー（Google、Apple、Facebook、GitHub、Microsoft、電話など）
  • 匿名認証（オンボーディングに便利）
  • メールリンク（パスワードレス）認証
  • Firebase UI——ドロップインの認証UIコンポーネント
  • 他のFirebaseサービスとの深い統合

注意点：

  • カスタムクレームは制限的で、設定にAdmin SDKが必要
  • 組み込みRBACなし——カスタムクレーム＋Security Rulesで自前実装
  • マルチテナンシーはIdentity Platform（有料アップグレード）が必要
  • ユーザーメタデータが限定的、プロフィールは別のFirestoreドキュメントで管理

Supabase Auth（GoTrue）

Supabase Authも大きく成長し、Firebaseと互角に渡り合えるようになっています：

// Supabase Auth — ソーシャルログイン
import { createClient } from '@supabase/supabase-js';

const supabase = createClient(SUPABASE_URL, SUPABASE_ANON_KEY);

const { data, error } = await supabase.auth.signInWithOAuth({
  provider: 'google',
  options: { redirectTo: 'https://yourapp.com/callback' },
});

強み：

  • OAuthプロバイダー（Google、Apple、GitHub、Discord、Slackなど）
  • Row Level Security（RLS）組み込み——認証がDBパーミッションと直接連動
  • ユーザーデータがauth.usersテーブルに存在し、SQLでクエリ可能
  • マジックリンク、電話OTP、SAML、SSO（Team/Enterprise）
  • RLSポリシーでauth.uid()を直接参照可能——ミドルウェア不要

注意点：

  • Firebaseより対応プロバイダーが少ない（約15 vs 20+）
  • 匿名認証に相当するネイティブ機能がない
  • リダイレクトベースのOAuthフローがFirebaseのポップアップより若干扱いづらい
  • SAML/SSOはTeam（$599/月）以上のみ

本当の違い：認可（Authorization）

認証（あなたは誰？）はほぼ同レベルです。**認可（何ができる？）**で大きく分かれます。

FirebaseはSecurity RulesというカスタムDSLを使います：

// Firestore Security Rules
rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /posts/{postId} {
      allow read: if true;
      allow create: if request.auth != null;
      allow update, delete: if request.auth.uid == resource.data.authorId;
    }
  }
}

Supabaseは**Row Level Security（RLS）**というPostgreSQLネイティブのポリシーを使います：

-- Supabase RLS ポリシー
ALTER TABLE posts ENABLE ROW LEVEL SECURITY;

CREATE POLICY "誰でもポストを閲覧可能"
  ON posts FOR SELECT USING (true);

CREATE POLICY "認証ユーザーのみ作成可能"
  ON posts FOR INSERT
  WITH CHECK (auth.uid() = author_id);

CREATE POLICY "著者のみ編集可能"
  ON posts FOR UPDATE USING (auth.uid() = author_id)
  WITH CHECK (auth.uid() = author_id);

どちらも同じことを実現しますが、Supabaseには構造的な利点があります：RLSポリシーはデータベースレベルで強制されます。 アプリから、cronジョブから、マイグレーションスクリプトから、直接SQL接続から、すべてのクエリが同じセキュリティチェックを通ります。FirebaseのSecurity RulesはFirestore SDKアクセスだけを保護します。Admin SDKでCloud Functionからアクセスすると、ルールはバイパスされます。

2026年、Supabaseはこの優位性をさらに強化しました：新規テーブルではRLSがデフォルトで有効になり、RLSなしのテーブルにはダッシュボードにセキュリティ警告が表示されます。さらに、パブリッシャブルキー（スコープ指定可能、ローテーション可能、GitHub流出時に自動失効）を含む新しいAPIキーシステムも導入されています。

リアルタイム：Firebaseの看板機能

率直に言います：リアルタイムはFirebaseが依然として圧倒的です。

Firebaseのリアルタイム

Firestoreのリアルタイムリスナーはシームレスで統合度が高いです：

import { onSnapshot, collection, query, where, orderBy } from 'firebase/firestore';

const q = query(
  collection(db, 'messages'),
  where('roomId', '==', currentRoomId),
  orderBy('createdAt', 'desc')
);

const unsubscribe = onSnapshot(q, (snapshot) => {
  snapshot.docChanges().forEach((change) => {
    if (change.type === 'added') console.log('新規:', change.doc.data());
    if (change.type === 'modified') console.log('更新:', change.doc.data());
    if (change.type === 'removed') console.log('削除:', change.doc.id);
  });
});

優れている理由：

  • オフラインファーストがデフォルト——ネット接続なしでも動作し、再接続時に自動同期
  • 自動コンフリクト解決
  • 細かい変更タイプ（added、modified、removed）
  • Web、iOS、Android、FlutterすべてにネイティブSDK
  • オプティミスティックUI更新が組み込み

これがFirebaseのキラーフィーチャーです。チャット、コラボレーションツール、ライブダッシュボードにおいて、Firebaseのリアルタイムは本当に超えるのが難しい壁です。

Supabaseのリアルタイム

Supabase RealtimeはPostgreSQLの論理レプリケーション上で動作します：

const channel = supabase
  .channel('messages-room')
  .on(
    'postgres_changes',
    {
      event: '*',
      schema: 'public',
      table: 'messages',
      filter: `room_id=eq.${currentRoomId}`,
    },
    (payload) => {
      console.log('変更受信:', payload);
    }
  )
  .subscribe();

Firebaseに劣る点：

  • オフラインファーストなし。 接続が切れるとイベントを取りこぼします。
  • 自動コンフリクト解決なし。
  • オプティミスティックUI なし。 アプリロジックで自前実装が必要。

追い上げている点：

  • Broadcast（Pub/Sub）とPresence（オンライン状態）チャネルをサポート
  • リアルタイムサブスクリプションにもRLSが適用——セキュリティ上の利点
  • cronジョブやマイグレーションからのデータ変更もリアルタイムイベントを発火

まとめ： リアルタイムがアプリの中核機能なら（チャット、コラボレーション、ライブゲーム）、Firebaseがまだ優位です。あると嬉しい付加機能なら（通知、ダッシュボードのライブ更新）、Supabaseで十分です。

ファイルストレージ

Firebase Cloud Storage

import { getStorage, ref, uploadBytes, getDownloadURL } from 'firebase/storage';

const storage = getStorage();
const storageRef = ref(storage, `avatars/${userId}/profile.jpg`);

await uploadBytes(storageRef, file);
const url = await getDownloadURL(storageRef);
  • 大容量ファイルのレジュマブルアップロード
  • Security Rulesによるアクセス制御
  • Google Cloud Storage基盤（事実上無制限のスケール）

Supabase Storage

const { data, error } = await supabase.storage
  .from('avatars')
  .upload(`${userId}/profile.jpg`, file, {
    cacheControl: '3600',
    upsert: true,
  });

const { data: { publicUrl } } = supabase.storage
  .from('avatars')
  .getPublicUrl(`${userId}/profile.jpg`);
  • 画像変換が組み込み——リサイズ、クロップ、フォーマット変換を外部サービスなしで即座に実行
  • RLSポリシーによるアクセス制御
  • S3互換API——移行が容易
  • TUSプロトコルによるレジュマブルアップロード

Supabaseの勝ち。 組み込みの画像変換だけでCloudinaryやImgixのような外部サービスが不要になります。Firebaseで変換するにはExtensions（Cloud Functions）が必要です。

Edge Functions / サーバーレス

Firebase Cloud Functions

import { onDocumentCreated } from 'firebase-functions/v2/firestore';
import { onRequest } from 'firebase-functions/v2/https';

export const onNewPost = onDocumentCreated('posts/{postId}', async (event) => {
  const data = event.data?.data();
});

export const api = onRequest(async (req, res) => {
  res.json({ status: 'ok' });
});
  • トリガー：Firestore、Auth、Storage、Pub/Sub、Scheduler、HTTP
  • 第2世代はCloud Runベース
  • Node.jsとPythonランタイム
  • コールドスタート：~500ms-2s
  • Firebase AI Logic——2026年の新機能、Gemini統合

Supabase Edge Functions

import { serve } from 'https://deno.land/std/http/server.ts';
import { createClient } from 'https://esm.sh/@supabase/supabase-js';

serve(async (req) => {
  const supabase = createClient(
    Deno.env.get('SUPABASE_URL')!,
    Deno.env.get('SUPABASE_SERVICE_ROLE_KEY')!,
  );

  const { data } = await supabase.from('users').select('*').limit(10);

  return new Response(JSON.stringify(data), {
    headers: { 'Content-Type': 'application/json' },
  });
});
  • グローバル分散——エッジで実行、ユーザーの近くで処理
  • Denoランタイム（TypeScriptネイティブ、ビルドステップ不要）
  • コールドスタート：平均~42ms（Deno 2アップグレードでの97%削減 — Firebaseよりはるかに高速）
  • 無料枠で月50万回呼び出し
  • Firestoreスタイルのトリガーなし（DBウェブフックやpg_notifyを使用）

核心的な違い： Firebase Cloud Functionsはネイティブトリガーが豊富。Supabase Edge Functionsは高速ですが、イベント駆動パターンには手動での接続が必要です。

料金：夢が覚めるところ

ここから比較が辛くなります。どちらも一見シンプルなモデルの裏に複雑さが潜んでいます。

Firebaseの料金

Firebase Blaze — 主要コスト：

Firestore：
  読み取り：  10万ドキュメントあたり$0.06（100万あたり$0.60）
  書き込み：  10万ドキュメントあたり$0.18（100万あたり$1.80）
  削除：      10万ドキュメントあたり$0.02（100万あたり$0.20）
  ストレージ：GB/月あたり$0.108

Cloud Functions：
  呼び出し：  100万あたり$0.40
  コンピュート：GB-秒あたり$0.00001667
  ネットワーク：送信GB/あたり$0.12

認証：ほとんどのプロバイダーで無料

料金の落とし穴——読み取り増幅（Read Amplification）：

1回のページロードで数百のドキュメント読み取りが発生しうることを知っていますか：

ユーザーがダッシュボードを開く：
  - ユーザープロフィール取得：    1読み取り
  - 最近の投稿20件：            20読み取り
  - 各投稿の著者情報：           20読み取り（JOINがないため！）
  - いいね数：                  20読み取り
  - コメント数：                20読み取り
  - 通知：                      10読み取り
  ---
  合計：1回のページロードで91読み取り

DAU 10,000人で試算すると、月間約2.73億読み取り。読み取りだけで月約$164になります。

Supabaseの料金

Supabase：

Free：    月$0
  - 2プロジェクト（7日間非アクティブで一時停止）
  - DB 500MB、ファイルストレージ 1GB
  - MAU 50K、Edge Function 50万回

Pro：     月$25 + 従量課金
  - DB 8GB、ファイルストレージ 100GB
  - MAU 100K、Edge Function無制限
  - 月$10コンピュートクレジット含む

Team：    月$599 — SSO、監査ログ
Enterprise：カスタム — HIPAA、SLA、専用インフラ

Supabaseの落とし穴——コンピュートアドオン：

Pro月$25には最小のコンピュートインスタンスしかつきません。プロダクションワークロードにはコンピュートの追加が必要です：

コンピュートアドオン（$10クレジット適用前）：
  Small  (2コアARM, 2GB RAM)：    ~月$15
  Medium (2コアARM, 4GB RAM)：    ~月$60
  Large  (2コアARM専用, 8GB RAM)： ~月$110

現実的なプロダクション構成：Pro(25)+Medium( 25) + Medium(~60) = ~$85/月。

MAUの罠： ProでMAU 10万を超えると、**1,000ユーザーあたり3.25∗∗の超過料金が発生します。MAU20万なら認証だけで月3.25**の超過料金が発生します。MAU 20万なら認証だけで月325加算です。

スケール時の料金比較

シナリオ：SaaS — DAU 50,000、MAU ~150K

Firebase (Blaze)：
  Firestore読み取り：  ~1.5億/月  = ~$90
  Firestore書き込み：  ~1,500万/月 = ~$27
  ストレージ＋Functions＋Storage  = ~$28
  認証：無料
  推定合計：                     ~$145/月

Supabase (Pro)：
  基本プラン：                   = $25
  コンピュート(Medium)：         = ~$60
  MAU：150K(50K超過 × $3.25)    = ~$162.50
  推定合計：                     ~$247.50/月

意外と近いですよね？ このシナリオではFirebaseの方がまだ安いのです。ただしページあたりの読み取り数を増やすと（非正規化でよくあること）、数字はすぐに逆転します。

正直な答え：どちらかが一貫して安いとは限りません。 必ず自分のワークロードでシミュレーションしてください。

ベンダーロックイン：脱出口

Firebaseのロックイン

率直に言って：Firebaseのロックインは大きいです。

  • Firestoreには標準クエリ言語がない——移行時にすべてのデータアクセスを書き直す必要あり
  • データモデル（ドキュメント/コレクション）がテーブル構造にきれいにマッピングされない
  • Security Rulesはプロプライエタリ
  • Cloud FunctionsのトリガーはFirebase固有

Firebaseからの移行は、中程度の複雑さのアプリで通常3-6ヶ月のプロジェクトになります。

Supabaseのロックイン

根本的に異なる状況です：

  • PostgreSQLがデータベースそのもの。pg_dumpで抽出して任意のPostgresホストにリストアできます
  • Edge FunctionsはDeno上で動作——標準ランタイム、コードが移植可能
  • Auth（GoTrue）はオープンソース——セルフホスト可能

Supabaseのロックインは回復可能（数週間の作業）。Firebaseのロックインは構造的（数ヶ月の作業）。脱出戦略が重要なら、これは決定的な差です。

2026年の開発体験

Firebase DX

  • Firebase Console——洗練されて使いやすい、非技術メンバーでも操作可能
  • Emulator Suite——Firestore、Auth、Functionsのローカルエミュレーション
  • Firebase Extensions（Stripe、Algolia、SendGrid等）
  • Firebase AI Logic——2026年新機能、Gemini統合
  • FlutterFire——ファーストクラスのFlutterサポート

Supabase DX

  • SQLエディタ、テーブルビューワー、RLSポリシーマネージャー
  • CLIでマイグレーション、TypeScript型自動生成、シードデータ
  • データベースブランチング——PR用プレビューDB（Team/Enterprise）
  • Claudeコネクター——自然言語でDB管理
  • Stripe Sync Engine組み込み

TypeScript体験の違い

Firebase： 型を手動定義してリファレンスをキャスト。自動生成なし。

Supabase： supabase gen types typescriptを実行すれば、DBスキーマ全体がTypeScript型になります。すべてのクエリが実際のスキーマに対して型チェックされます。生産性の面で本物の優位性です。

いつどちらを選ぶべきか

Firebaseを選ぶ場面：

  • リアルタイム同期が中核機能。 チャット、コラボエディタ、ライブゲーム——Firebaseのオフラインファーストリアルタイムは本当に優秀。
  • モバイルファースト。 iOS、Android、FlutterのネイティブSDKがより成熟し深く統合されている。
  • チームがSQLに不慣れ。 Firestoreのドキュメントモデルはフロントエンド開発者にとって取っつきやすい。
  • Googleエコシステムを使っている。 GCP、BigQuery、Vertex AIとシームレスに統合。
  • データが階層的。 IoTセンサー、チャットスレッド、ソーシャルフィード——自然にネストするデータならFirestoreの方がシンプル。

Supabaseを選ぶ場面：

  • データがリレーショナル。 ユーザー、注文、商品、レビュー——エンティティ間の参照をPostgreSQLがネイティブに処理。
  • SQLのフルパワーが必要。 複雑な集計、ウィンドウ関数、CTE、全文検索、JSONB、マテリアライズドビュー。
  • 型安全性が重要。 スキーマから自動生成されるTypeScript型で、バグのカテゴリーを丸ごと排除。
  • 脱出戦略が重要。 Postgresベースなら、いつでも離れられる。
  • 画像変換が必要。 サードパーティサービスなしでリサイズ、クロップ、フォーマット変換が組み込み。

ハイブリッドアプローチ

あまり語られませんが、両方使うチームもあります：

  • Supabaseでリレーショナルコア（ユーザー、注文、商品、ビジネスデータ）
  • Firebaseでリアルタイム機能（チャット、通知、ライブ更新）

運用の複雑さは増しますが、適切なユースケースでは両方の長所を活かせます。

比較記事が触れないこと：持続可能性

FirebaseはGoogleが後ろ盾です。安定していますが、Googleには製品をサンセットしてきた歴史もあります（GCM、Firebase Predictions、Fabricなど）。

SupabaseはVC出資（~$116M+）を受けています。オープンソースなので、会社の方針が変わってもデータが閉じ込められることはありません。

今後の展望：収束

FirebaseはData ConnectでSQLの方向へ、AI LogicでGemini統合へ、Firestore Enterprise Editionでパイプライン操作へ。

Supabaseはより良いリアルタイム、AI統合（pgvectorベクトル検索、Claudeコネクター）、プラットフォーム完成度（Stripe Sync、DBブランチング）へ。

両者は互いの強みに向かって収束しています。5年後には差はもっと小さくなっているでしょう。でも今はまだ、違いが意思決定に影響する程度には大きいです。

まとめ

率直な真実：どちらも優れた選択肢です。 FirebaseもSupabaseもプロダクション実績のある成熟したプラットフォームです。

一言でまとめるなら：

動くアプリへの最短ルートがFirebase。メンテナブルなアプリへの最強ルートがSupabase。

Firebaseはゼロからデプロイまでが速い。特にリアルタイムアプリとモバイルファーストプロジェクトで。学習曲線が緩やかで、エコシステムが洗練されています。ただしデータが複雑になると、SQLの不在を痛感することになります。

Supabaseは初期投資が多い（スキーマ、SQL、RLSポリシー）。でもその投資は複利で返ってきます。型安全なクエリ、外部キー、マイグレーション管理されたスキーマが、アプリの成長とともに真価を発揮します。そして離れる必要が出たとき、離れることができます。

実際のアドバイス：チームが知っているデータベースで始めてください。 SQLで考えるチームならSupabase。ドキュメントで考えるチームならFirebase。BaaSレイヤーより、データモデルの方がずっと長く残ります。

いいものを作って、シップして、本当に大事な問題に取り組みましょう。

SupabaseFirebaseBaaSPostgreSQLFirestorebackenddatabaseserverless

関連ツールを見る

Pockitの無料開発者ツールを試してみましょう

PDF結合
散らばった書類をひとつにまとめましょう。ドラッグ＆ドロップで順番を決め、安全かつ瞬時にPDFを結合します。
使ってみる
PDF分割
必要なページだけを取り出せます。大きなドキュメントを分割したり、特定のページだけを安全に抽出して保存できます。
使ってみる
JSONフォーマッター
乱雑なデータを見た目良く整理しましょう。JSONの構文エラーを自動で修正し、読みやすい形式に整形します。
使ってみる
ハッシュ生成
データの指紋を作成します。テキストからMD5やSHAハッシュを生成し、データの改ざんがないかを検証できます。
使ってみる
画像サイズ変更
画像のサイズを変更したいですか？パーセント指定、ピクセル指定、InstagramやYouTube用プリセットで簡単リサイズ。複数画像の一括処理も可能。サーバーへのアップロード不要で100%安全です。
使ってみる
オンライン画面録画
透かしなしの高画質で画面をキャプチャ。ブラウザだけで無制限に動画と音声を録画—データがサーバーに送信されることはありません。
使ってみる