✍️ 필사 모드: Backend-as-a-Service 2026 — Supabase・Firebase・Pocketbase・Appwrite・Convex・InstantDB 徹底比較(1 人 SaaS の背骨) (日本語)

プロローグ — 「1 人 SaaS」の背骨を何で組むか

2026 年 5 月。新規プロジェクトの最初の会議は、2020 年と妙に似ていて、しかし違う。

「バックエンド、自分で書く?それとも BaaS 使う?」

違いは、もはや 「BaaS を使わないチームがほとんどいない」 ことだ。1 人 SaaS、インディゲーム、サイドプロジェクト、シードのスタートアップまで。フルスタックの裏側をゼロから書くのはコストが高すぎる。認証・ストレージ・リアルタイム・ベクター・DB・エッジ関数を全部手で書くのは、「AI で 1 人が SaaS を作る」 という 2026 年の流れと真正面からぶつかる。

BaaS の地形そのものも 5 年前と違う。

• Firebase 一強の時代は終わった。 Google の巨人は依然として大きな市場を持つが、本物のナンバーツーが現れた — Supabase、Postgres ベースのオープンソース代替だ。
• セルフホスト BaaS が一カテゴリとして定着した。 Appwrite と Pocketbase がそれぞれの席を確保し、両者とも v1.x 系列で安定期に入った。
• 新しいモデル「リアクティブ バックエンド」が登場した。 Convex は関数結果をクライアントが購読するモデルで席を取り、「サーバーコンポーネントと同居するバックエンド」を標榜する。
• InstantDB は「Firebase + Linear」の道を選んだ。 タグ付きテンプレート + リアルタイムグラフクエリで、「Vercel 時代に Firebase が生まれ変わったらこうなる」と評される。

本稿は 2026 年 5 月時点で、7 つの選択肢を比較する。

• Supabase — Postgres ベースのオープンソース BaaS の事実上の標準
• Firebase — 依然最大の BaaS、Google Cloud 連携と Genkit で AI 時代へ
• Pocketbase — 単一 Go バイナリ + SQLite、インディプロジェクトの第一選択
• Appwrite — マルチ機能のフル BaaS、セルフホスト指向
• Convex — リアクティブ バックエンド、TypeScript ネイティブの関数
• InstantDB — リアルタイム TS-first クエリ、「Vercel 時代の Firebase」
• PlanetScale + Clerk + 自前 — BaaS を拒否して組み合わせる道

比較軸は 7 つ — データモデル・リアルタイム・認証・ベクター/AI・セルフホスト・ベンダーロックイン・スケール時の価格。最後はシナリオ別の推薦で締める。

1 章 · 地形 — 何が BaaS で、誰と誰が戦うか

まず分類から。みんな「BaaS」と呼ぶが、形は違う。

本稿の中心は太字の 6 つ — Supabase・Firebase・Pocketbase・Appwrite・Convex・InstantDB。最後に自前組み合わせを短く扱う。

なぜこの 6 つか

• Supabase — BaaS 市場の 2 位。GitHub スター 78k+、オープンソース フル BaaS の事実上の標準。DataLab・SQL Editor v2・Branching が直近 1 年の大きな変化。
• Firebase — Google の巨大 BaaS、モバイル向き。App Hosting と Genkit で AI 時代に入った。Firestore は依然としてホストされたドキュメント DB の圧倒的首位。
• Pocketbase — 単一 Go バイナリ、SQLite ベース。v0.22 系列で安定し、1 人インディプロジェクトの事実上の第一選択。GitHub スター 42k+。
• Appwrite — セルフホスト指向のフル BaaS。v1.6 ~ v1.7 で Functions・Realtime・Storage が安定。Appwrite Cloud はホスト版として GA。
• Convex — TypeScript ネイティブのリアクティブ バックエンド。関数 + 自動キャッシュ + WebSocket 購読で、「サーバーコンポーネントと同居するバックエンド」を標榜。
• InstantDB — 2024 年ベータ以降、2025~2026 で急成長。TS-first クエリ(useQuery({ todos: {} }))と強力なルールモデルが核。

2 章 · データモデル — SQL かドキュメントかグラフか

BaaS 選択の最初の分岐は データモデル だ。間違えると半年後に後悔する。

リレーショナル(SQL)         ドキュメント              グラフ/リアクティブ
     |                          |                          |
Supabase   Appwrite(SQL)   Firebase(Firestore)   InstantDB   Convex
Pocketbase(SQLite)          Appwrite(Docs)        Firestore Datastore

2.1 Supabase — Postgres そのもの

Supabase の本質は 「Postgres に BaaS の皮を被せた」 こと。データは本物の Postgres テーブルに入り、JOIN・トリガー・MV・CTE が普通に使える。

-- Supabase は本物の Postgres なのでそのまま動く
CREATE TABLE posts (
  id uuid PRIMARY KEY DEFAULT gen_random_uuid(),
  author_id uuid REFERENCES auth.users (id),
  title text NOT NULL,
  body text,
  created_at timestamptz DEFAULT now()
);

-- Row Level Security が権限モデルの中心
ALTER TABLE posts ENABLE ROW LEVEL SECURITY;
CREATE POLICY "own_posts" ON posts
  USING (author_id = auth.uid());

強み

• 関係が明確な SaaS・B2B・CRUD 中心アプリに自然。
• 運用ノウハウは普通の Postgres 知識(export・チューニング・インデックス)。
• pgvector 拡張がビルトイン。AI アプリ向き。

弱み

• ドキュメント/埋め込みグラフ的データには自然でない。
• トランザクション + リアルタイム + RLS の相互作用が最初は分かりにくい。

2.2 Firebase Firestore — ドキュメントの王

Firestore は コレクション + ドキュメント + サブコレクション の NoSQL ドキュメント DB。スキーマレスで、クライアントから直接読み書きが標準モデル。

import { getFirestore, collection, addDoc } from 'firebase/firestore'

const db = getFirestore()
await addDoc(collection(db, 'posts'), {
  authorId: 'user_123',
  title: 'Hello',
  createdAt: serverTimestamp(),
})

強み

• モバイル・オフライン同期の事実上の標準。
• 権限は Security Rules で宣言的に。
• 自動スケール、トラフィック急増にもまず落ちない。

弱み

• JOIN が無い。リレーショナルデータは非正規化と複製で解く。
• クエリ表現力に制限(事前定義インデックス、OR 制約など)。
• 料金が「ドキュメント読み取り回数」連動 — スケール時のコストモデリングが難しい。

2.3 Pocketbase — SQLite ベースの綺麗なリレーショナル

Pocketbase は SQLite の上にコレクションモデルを乗せた形。「ドキュメントっぽいが実はリレーショナル」のハイブリッド。

• コレクション = SQLite テーブル(スキーマあり)。
• レコード間の関係は relation フィールド型で表現。
• 管理 UI でスキーマとレコードを視覚的に管理。

強み

• 単一バイナリ。./pocketbase serve 一行で開始。
• SQLite の単純さ — バックアップはファイルコピー、運用コストはほぼゼロ。

弱み

• 単一ノード。水平スケールは本質的に難しい(LiteFS で迂回はある)。
• SQLite の限界 — 並行書き込み・複雑クエリ・拡張モジュールでは Postgres に劣る。

2.4 Appwrite — ドキュメント型、マルチバックエンド

Appwrite はドキュメント/コレクションモデルだが、内部的に MariaDB・MySQL・MongoDB を選べる。運用者が自分のインフラに合わせて選べるのが強みでもあり複雑さでもある。

2.5 Convex — ドキュメント + reactive ビュー

Convex のデータモデルは ドキュメント + インデックス + 関数。データを直接公開せず、常に TypeScript 関数 を経由して見る。

// convex/posts.ts
import { query } from './_generated/server'

export const list = query(async (ctx) => {
  return await ctx.db.query('posts').order('desc').take(20)
})

// クライアントは関数結果を購読する — 自動でリアルタイム
const posts = useQuery(api.posts.list)

2.6 InstantDB — トリプルストア + グラフクエリ

InstantDB は entity-attribute-value(トリプルストア) モデルの上にグラフクエリ層を持つ。

import { useQuery } from '@instantdb/react'

// 「todos を取って、その中の owner も一緒に」
const { data } = useQuery({ todos: { owner: {} } })

スキーマは任意 — スキーマなしで始めて、徐々に強化できる。

3 章 · リアルタイム — 「プッシュ」が標準か任意か

2026 年の BaaS において、リアルタイムは 任意ではなく標準。ただし実装モデルは違う。

3.1 Supabase — RLS とリアルタイムの邂逅

Supabase Realtime は Postgres の論理レプリケーションを聞いていて、RLS ポリシーを満たす変更だけをクライアントにプッシュする。

const channel = supabase
  .channel('posts')
  .on('postgres_changes',
      { event: '*', schema: 'public', table: 'posts' },
      (payload) => { /* ... */ })
  .subscribe()

RLS がリアルタイムにも適用される — 一か所でポリシーを書けば、読み・書き・リアルタイム全部を同じポリシーで守れる。

3.2 Firestore — 最も滑らかなモバイル リアルタイム

onSnapshot はモバイル向きリアルタイムの事実上の標準。オフラインキュー、自動再接続、コレクションインデックスまで束ねられる。

3.3 Convex — 関数結果がそのまま購読単位

Convex の違いは 「クエリ関数の結果自体が購読単位」 という点。関数が読んだデータを自動追跡し、それが変わると関数を再実行してクライアントに新結果をプッシュする。

「どのチャネルを購読するか?」のような悩みが消える。ただし料金モデル・関数の書き方が一般 BaaS と違うので学習コストがある。

3.4 InstantDB — グラフ差分そのままプッシュ

InstantDB はクライアントが書いたグラフクエリ({ todos: { owner: {} } })をそのまま購読する。どの attribute が変わったか、サーバが知っている。

4 章 · 認証・権限 — 本当に運用可能か

BaaS の本当の価値は認証・権限システムにある。自分で書いた人は知っている — トークン回転・OAuth コールバック・メール確認・MFA・RLS がどれだけ面倒か。

4.1 Supabase Auth + RLS

中心は JWT + Postgres RLS。JWT の sub が auth.uid() 関数として全クエリで使える。

CREATE POLICY "select_own" ON posts FOR SELECT
  USING (author_id = auth.uid());

CREATE POLICY "insert_own" ON posts FOR INSERT
  WITH CHECK (author_id = auth.uid());

RLS は データ自体に権限が刻まれる ので強力だが、デバッグ難度がある — ポリシーを間違えると「原因不明の空結果」になる。

4.2 Firebase Security Rules

宣言的 DSL で権限を書く。

match /posts/{postId} {
  allow read: if true;
  allow write: if request.auth.uid == resource.data.authorId;
}

学習コストはあるが、慣れると非常に強力。

4.3 Convex — 関数内チェック

Convex には RLS のような DB レベル権限が無い。すべての権限チェックは関数内。

export const updatePost = mutation(async (ctx, { id, body }) => {
  const identity = await ctx.auth.getUserIdentity()
  if (!identity) throw new Error('unauthorized')
  const post = await ctx.db.get(id)
  if (post.authorId !== identity.subject) throw new Error('forbidden')
  await ctx.db.patch(id, { body })
})

長所は明示性 — 権限がコードに見える。短所は一貫性 — すべての関数に手で書く必要がある。

4.4 InstantDB Rules

InstantDB は Datalog 風のルール DSL を使う。データモデルがトリプルストアなのでルール言語もその形に合う。

5 章 · AI・ベクター — 2026 年の BaaS の差別化点

2026 年の BaaS で最も急進化した領域が ベクター・埋め込み・AI 機能 だ。

5.1 Supabase — pgvector の本拠地

Supabase の AI 親和度が最高と評される理由は pgvector を 1 級扱い している点。

CREATE EXTENSION vector;

CREATE TABLE documents (
  id bigserial PRIMARY KEY,
  content text,
  embedding vector(1536)
);

CREATE INDEX ON documents USING hnsw (embedding vector_cosine_ops);

RAG・埋め込み検索・セマンティック検索が普通の Postgres クエリで書ける。AI アプリで BaaS とベクター DB を分ける必要が無い。

5.2 Firebase Genkit — Google の回答

Genkit は Firebase 側の AI フレームワークで正式に GA。Vertex AI 連携、Gemini モデル、retrieval、flow definition、評価まで束ねる。Firebase バックエンド + Genkit AI フローを一緒に書きたいチームに自然。

5.3 Convex — 関数内で LLM 呼び出しが標準

Convex 関数の中で OpenAI・Anthropic API を直接呼ぶパターンが標準化されている。ベクターインデックスがビルトインで RAG パイプラインが短い。

// convex/rag.ts
export const search = query(async (ctx, { q }) => {
  const embedding = await embed(q)
  const docs = await ctx.db
    .query('docs')
    .withIndex('by_embedding', q => q.vectorSearch('embedding', embedding))
    .take(5)
  return docs
})

6 章 · セルフホスト ストーリー — 「1 人 SaaS」では核心

セルフホストは単なるコスト削減ではなく、ベンダーロックインを断つ保険 だ。

6.1 Pocketbase — 最もシンプル

Pocketbase のセルフホストは 1 分。

# バイナリをダウンロード後
./pocketbase serve --http=0.0.0.0:8090

Fly.io・Railway・任意の VPS — 単一バイナリと SQLite ファイルが全構成。バックアップはそのファイルをコピー。

6.2 Supabase — 強力だが運用コストあり

Supabase のセルフホストは可能だが、複数サービス(Postgres + GoTrue + Realtime + Storage + Studio + ...)を一緒に運用 する必要がある。Docker compose で開始はできるが、本番運用には真剣な運用工数が必要。

6.3 Appwrite — Docker 親和

Appwrite はセルフホストが 1 級市民。docker-compose up -d で全スタックが立ち上がる。インディと小規模チームに自然。

6.4 Convex — OSS 登場

2025 年後半に Convex が OSS セルフホスト版を公開。ホスト版と 100% 同等ではないが、ロックインを本気で減らした。

6.5 Firebase — 不可能

Firebase にはセルフホストオプションが無い。ローカルエミュレータは開発用。これが Firebase の最大の弱点。

7 章 · ベンダーロックイン — 抜けられるか

セルフホストとは別に、データ・コード・運用知識の可搬性 がロックインの本質だ。

Supabase が最低の理由

Supabase の真の強みは 「データはただの Postgres」 ということ。pg_dump で他の Postgres にそのまま入る。SDK も PostgREST・GoTrue といった標準の上にあるので乗り換えコストが低い。

Firebase が最高の理由

Firestore export → 他 DB は自動ではない。モデルが違い(ドキュメント → リレーショナル写像が必要)、Security Rules・トリガー・Functions は Google Cloud に埋め込まれている。ロックインが本質的だ。

8 章 · 料金・スケール — 「エッジケース」が決める

料金比較は単純な表ではない。「何が課金単位か」 が核心だ。

料金の罠

最もよくある誤りは 「無料 tier が手厚い」だけ見て決めること。

• Firebase は「ドキュメント read」が課金単位なので、「1 ページで 50 ドキュメント表示するアプリ」はユーザ 1 人ページビュー毎に 50 回 read。トラフィックが増えると曲線が急。
• Supabase は Postgres + Egress 中心で、大きなペイロード(画像・大きな JSON)が Egress を急増させる。
• Convex は関数呼び出し + WebSocket 時間。常時接続のモバイルクライアントが多いと急。

1 人 SaaS シナリオ(月 1,000 ユーザ)

おおよそ(正確な数字は常に最新の料金ページ確認)。

• Supabase Pro — 月 $25 から + 使用量 + Egress。
• Firebase — 無料 tier + 超過分は Blaze 従量。read 回数依存。
• Pocketbase — VPS 月 $5~$10。それ以外はほぼゼロ。
• Appwrite Cloud — 無料 + 使用量。セルフホストは無料。
• Convex — 月 $25 から + 使用量。
• InstantDB — 無料 + 使用量。

この段階では Pocketbase・セルフホスト Appwrite が圧倒的に安い。代わりに運用は自分の時間。

シード SaaS シナリオ(月 5 万ユーザ)

• 1 人セルフホスト運用は厳しくなる。VPS 監視・バックアップ・アップグレード。
• Supabase Pro / Convex / Firebase Blaze が自然な選択。
• Firebase は read 回数モデリングを誤ると一気に高くなる。
• Supabase は一貫した Postgres 運用 + Egress 管理が肝。

9 章 · 7 軸比較 — ひと目で

9.1 コア マトリクス

9.2 シナリオ別 推薦

AI アプリ(RAG・埋め込み・LLM フロー)

1. Supabase — pgvector + Edge Functions、最も滑らか。
2. Convex — 関数 + ベクター ビルトイン、TS-first。
3. Firebase + Genkit — Google 陣営を既に使っている場合。

B2B SaaS(関係データ・複雑クエリ)

1. Supabase — Postgres が第一。
2. PlanetScale・Neon + Clerk + 自前バックエンド — 自前組み合わせ陣営。
3. Convex — TS-first チームで reactive を望む場合。

モバイル優先(オフライン・プッシュ通知)

1. Firebase — 依然事実上の標準。オフライン同期が成熟。
2. Supabase — モバイル SDK 進化中だが、オフラインはまだ Firebase 水準ではない。
3. InstantDB — リアルタイム グラフがモバイル UX に合う。

1 人 SaaS・インディ・サイドプロジェクト

1. Pocketbase — 単純さの価値が圧倒的。
2. Supabase — 無料 tier + Postgres 運用知識の再利用。
3. InstantDB — 小チーム + リアルタイム向き。

セルフホスト優先(規制・セキュリティ・コスト)

1. Appwrite — Docker 一行、フルスタック。
2. Supabase セルフホスト — 強力だが運用コスト。
3. Pocketbase — 最もシンプル。

10 章 · 自前組み合わせ — BaaS を拒否する道

最後のカード。意識的に BaaS を拒否し、各責務を別サービスで組むチームもいる。

Auth        Clerk / WorkOS / Auth.js
DB          PlanetScale / Neon / Supabase Postgres(のみ)
Realtime    Liveblocks / Ably / 自前 WS
Storage     S3 / R2 / UploadThing
Functions   Inngest / Cloudflare Workers
Email       Resend
Vector      Pinecone / Turbopuffer / pgvector

強み

• 各責務に最高のツールを選べる。
• 一つの障害が全体を止めない。
• 価格曲線を細かく制御できる。

弱み

• 統合コスト。認証・DB・リアルタイム間のつなぎを自分で書く。
• 障害時のデバッグ面積が広い。
• 新メンバーのオンボーディングで N 個のツールを教える必要。

いつ良いか

• Series A 以降、10 人以上のエンジニア。
• 特定ツールの限界を明確に見たあと。
• 規制・SLA・オンプレ要件が強いとき。

11 章 · この 1 年で何が変わったか

各ツールの 2025~2026 年の主な変更。

Supabase

• DataLab — ノートブック スタイルの SQL 分析ツール。Postgres + AI アシスタントでデータ探索。
• SQL Editor v2 — 高速化と AI 自動補完強化。
• Branching — DB ブランチ機能が GA。PR 毎に isolated DB。
• pgvector + HNSW インデックス安定化。
• Edge Functions のコールドスタート改善。

Firebase

• App Hosting GA — Next.js・Angular ホスティングが 1 級に。
• Genkit GA — AI フローフレームワーク正式リリース。
• Data Connect — リレーショナル(Postgres)連携がビルトイン。
• Firestore 料金モデル調整。

Pocketbase

• v0.22 系列で安定化。
• Realtime SSE 性能改善。
• 外部 OAuth プロバイダ拡充。
• Go API のクリーンアップ。

Appwrite

• v1.6 → v1.7 — Functions・Realtime・Sites が安定化。
• Appwrite Cloud GA。
• Sites — 静的サイトホスティングがビルトイン。

Convex

• OSS セルフホスト公開。
• ベクター検索 GA。
• HTTP Actions・Crons・Scheduling 安定化。
• Next.js・TanStack Start 連携。

InstantDB

• ベータ → GA(段階的)。
• 権限ルールシステム強化。
• セルフホスト ベータ提供。
• Clerk・Auth.js 連携。

エピローグ — 「1 人が SaaS を作る」時代の道具選び

BaaS 選択は 「何を課金単位として受け入れるかの意思決定」 でもある。1 年後の請求書を頭の中で先に描くことが、価格表を暗記するより大事だ。

2026 年 5 月時点の結論。

• Postgres に乗れるなら Supabase — ロックイン低、運用知識は普通の Postgres 知識。
• モバイル・オフラインが本質なら Firebase — ロックインは高いが成熟度は無類。
• 1 人・インディ・小規模は Pocketbase が正解のことが多い — 単純さがそのまま速度。
• セルフホスト フルスタックは Appwrite — Docker 親和、自分のインフラで判断。
• TS-first リアクティブ バックエンドは Convex — 関数 + 購読モデルに慣れると魅力。
• リアルタイム グラフ + 小さなコードは InstantDB — 急速成長中。
• 何を作るか明確なら自前組み合わせ — ただし統合コストは本物。

意思決定 チェックリスト

• データモデルはリレーショナルか?ドキュメントか? — リレーショナルなら Supabase・Pocketbase。ドキュメントなら Firebase・Appwrite・Convex・InstantDB。
• リアルタイムが本質か? — Yes なら Convex・InstantDB・Supabase・Firestore。
• モバイル + オフライン同期? — Yes なら Firebase 第一。
• AI・ベクター・RAG が中心? — Supabase・Convex。
• セルフホスト必須? — Pocketbase・Appwrite・Supabase・Convex。
• ロックイン最小? — Supabase・Pocketbase。
• 最速 MVP? — Firebase・Pocketbase・Convex。

アンチパターン

1. 無料 tier だけで判断する — 1 年後の請求書は曲線。課金単位を見よ。
2. 「トレンド」だけで乗り換える — Convex がかっこよく見えて移ったが、RLS 風の権限が恋しくなるケース多数。
3. SLA 計算なしの 1 人セルフホスト — バックアップ・監視・アップグレードは自分の時間。
4. Firebase で日 30 万 read を無料 tier 内と仮定する — 課金モデルを先にモデリング。
5. BaaS A と B を同時に使う — 「認証は Firebase、DB は Supabase」。統合コストで一シーズン消える。
6. ロックイン 0 を追求して何も作れない — ロックインはトレードオフ、ゼロは不可能。
7. AI アプリなのにベクター ビルトイン無しを選ぶ — BaaS の価値の半分が消える。

次回予告

• Supabase Branching + Drizzle ORM 1 年の回顧 — PR 毎 isolated DB が実際どうだったか
• Firebase Genkit vs Vercel AI SDK 実戦比較 — 同 RAG フローでの一騎打ち
• Pocketbase 単一バイナリで 6 ヶ月 SaaS 運営の正直な感想
• Convex OSS セルフホスト — ホスト版と実際何が違うか

「BaaS とはバックエンドを書く仕事ではない。バックエンドを書かないという意思決定を書く仕事だ。」

— BaaS 2026、終。

参考 / References

• Supabase — 公式
• Supabase Docs
• Supabase GitHub
• Supabase Branching
• Supabase pgvector
• Firebase — 公式
• Firebase App Hosting
• Firebase Genkit
• Firebase Data Connect
• Firestore Security Rules
• Pocketbase — 公式
• Pocketbase GitHub
• Pocketbase Docs
• Appwrite — 公式
• Appwrite GitHub
• Appwrite Cloud
• Convex — 公式
• Convex Docs
• Convex GitHub
• Convex Self-Hosting
• InstantDB — 公式
• InstantDB Docs
• InstantDB GitHub
• Clerk — Auth
• PlanetScale
• Neon — Serverless Postgres
• Inngest — Background Jobs
• Liveblocks — Realtime
• Vercel AI SDK