Supabase は、PostgreSQLを中心に「欲しい機能がだいたい揃ってる」優れたBaaSです。一方で、プロダクトが伸びる前段の個人開発やMVPだと「まず固定費を抑えたい」「リソース使用量が読めない」といった理由で、コストが気になる場面もあります。関連記事は baas と supabase にまとめています。
自分は なんでも解説動画ジェネレーター で、ジョブキュー管理のために PocketBase を採用しました。理由は単純で、要件がそこまで複雑ではなく、運用コストを最小にしたかったからです。
本記事では、PocketBaseを「Supabaseの代替」として雑に推すのではなく、PocketBaseを選ぶべき条件（そして選ぶべきでない条件）を整理します。どちらも素晴らしいサービスで、勝ち筋は要件次第です。
Supabaseのコスト構造を理解する
クラウド版の料金（Free / Pro / Team）
Supabase Cloudの料金は Supabase Pricing にまとまっています。
- Free: まず試すには十分。ただし「本番運用の安定性」「上限」「サポート」など、どこかで壁に当たります。
- Pro: $25/月〜 が起点になりやすいです（プロジェクト単位の固定費として効いてくる）。
- Team: チーム運用・権限・監査など、組織向けの要件が主軸です。
ここで大事なのは「Supabaseが高い」ではなく、クラウド運用で面倒な部分（DB運用、バックアップ、監視、アップデートなど）を丸ごと引き受けてくれる分、固定費が発生する、という構造です。
セルフホストの現実（複雑さと必要リソース）
Supabaseはセルフホストもできますが、実運用に乗せると現実的なコストが見えてきます。
- 構成がシンプルではない: supabase/supabase のDocker Composeはコンポーネントが多く、全体を理解して保守する必要があります。
- 必要リソースがそれなり: 「4GB+ RAM推奨」「10+コンテナ構成」あたりが、最低ラインとして効いてきます（プロジェクト規模・ワークロードで上下します）。
- VPS代だけでは終わらない: バックアップ、監視、アップグレード、障害対応の“人件費”がじわじわ来ます。
つまり「月額は下がったが、運用責務が増えた」という状態になりがちです。ここを受け入れられるかが分岐点です。
PocketBaseという選択肢
PocketBaseは、単一バイナリで動く軽量BaaSです。データストアはSQLiteで、認証・ストレージ・リアルタイム購読が一体になっています。
特徴（刺さるところだけ）:
- 単一バイナリ（公式いわく約12MB）で、デプロイが簡単
- SQLite（WALモード）で、運用が軽い
- 認証・ファイルストレージ込みで「まず動く」までが速い
- Go/JavaScriptで拡張できる一方、Cloud Functionsのようなマネージド実行基盤はありません
なお、PocketBaseは現時点で v1.0 未満です。また、水平スケーリング（同一アプリを複数台に増やして分散する）は前提としていません。この制約は、後述の「向かないケース」に直結します。
機能比較
両者の機能を整理します。「どちらが優れているか」ではなく、「何ができて、何ができないか」を把握するのが目的です。
データベース
| 機能 | Supabase | PocketBase |
|---|---|---|
| DB エンジン | PostgreSQL | SQLite（WALモード） |
| SQL クエリ | フル SQL 対応 | 制限付き（フィルタ構文） |
| JOIN / ビュー / 関数 | ○ | × |
| トランザクション | ACID 完全対応 | 単一ライタ制約あり |
| 拡張機能（pgvector等） | ○ | × |
| スキーマ管理 | マイグレーション + GUI | コレクション定義 + GUI |
Supabaseは「PostgreSQLそのもの」なので、複雑なクエリや拡張機能が使えます。PocketBaseはSQLiteベースで、シンプルなCRUDに特化しています。
認証
| 機能 | Supabase | PocketBase |
|---|---|---|
| メール/パスワード | ○ | ○ |
| OAuth（Google, GitHub等） | ○（多数対応） | ○（15+プロバイダ） |
| マジックリンク | ○ | ○ |
| 電話認証（SMS） | ○ | × |
| MFA（多要素認証） | ○ | × |
| SAML / SSO | ○（Team以上） | × |
| Row Level Security | ○（PostgreSQL RLS） | ○（コレクションルール） |
認証の基本機能は両者とも揃っています。エンタープライズ向け（MFA、SAML）が必要ならSupabase一択です。
ストレージ
| 機能 | Supabase | PocketBase |
|---|---|---|
| ファイルアップロード | ○ | ○ |
| アクセス制御 | RLS ベース | コレクションルール |
| 画像変換（リサイズ等） | ○ | × |
| CDN | ○（Smart CDN） | × |
| 最大ファイルサイズ | 500GB（Pro） | 設定次第 |
Supabaseはストレージ機能が充実しています。PocketBaseは「ファイルを保存できる」レベルで、画像変換やCDNは自前で用意する必要があります。
リアルタイム
| 機能 | Supabase | PocketBase |
|---|---|---|
| DB 変更の購読 | ○（Postgres Changes） | ○（コレクション購読） |
| Broadcast（任意データ配信） | ○ | × |
| Presence（オンライン状態） | ○ | × |
| 同時接続数（目安） | プランによる | 10,000+（$4 VPS） |
リアルタイム機能は両者ともDB変更の購読に対応しています。Supabaseはチャットやコラボレーション向けのBroadcast/Presenceも備えています。
サーバーサイドロジック
| 機能 | Supabase | PocketBase |
|---|---|---|
| Edge Functions | ○（Deno） | × |
| DB トリガー / 関数 | ○（PostgreSQL） | × |
| カスタムフック | × | ○（Go / JS） |
| 拡張方法 | マネージド関数 | バイナリに組み込み |
ここが設計思想の違いです。Supabaseは「マネージドな関数実行基盤」を提供し、PocketBaseは「フレームワークとして拡張する」アプローチです。PocketBaseでカスタムロジックを書く場合、Go/JSでフックを実装し、バイナリをビルドし直す必要があります。
運用・管理
| 機能 | Supabase | PocketBase |
|---|---|---|
| 管理ダッシュボード | ○（高機能） | ○（シンプル） |
| CLI | ○ | ○ |
| バックアップ | 自動（Pro以上） | 手動 or Litestream |
| ログ / 監視 | ○（Log Drain対応） | 基本ログのみ |
| マイグレーション | ○（supabase db push） | ○（pb_migrations） |
Supabaseは運用ツールが充実しています。PocketBaseは「シンプルに動く」ことを優先しており、監視やバックアップは自前で構築します。
コスト比較（ざっくり）
前提: ここでは「まず本番で回す」最小構成の固定費をイメージします。実際のコストは、トラフィック・データ量・運用体制で大きく変わります。
| 選択肢 | 月額の目安 | 運用コスト（手間） | どんなときに効くか |
|---|---|---|---|
| Supabase Cloud Pro | $25+ | 低い（マネージド） | DB運用を避けたい、PostgreSQL前提の設計 |
| Supabase Self-hosted | VPS $20〜（例）+ 付随コスト | 高い（自分で見る） | クラウド固定費を下げたいが運用を持てる |
| PocketBase | VPS $4〜 | 低〜中（単一ノード運用） | シンプル要件で、固定費を極小にしたい |
「PocketBaseは$4のVPSで動く」という話は、PocketBase FAQ の文脈（1台運用、想定接続数の話）に近いです。具体的には Hetzner CAX11（2vCPU、4GB RAM）で10,000+のリアルタイム接続が可能とされています。接続数や性能は環境依存なので、数値は目安として捉えてください。
PocketBaseを選ぶべき条件
✅ 向いているケース
- 個人開発・MVP: まず固定費を抑えて、当たったら移行する前提で割り切れる
- 社内ツール: 同時接続やSLAがそこまで厳しくない、CRUD中心
- シンプルなCRUD: 複雑なSQL・高度なRLS（Row Level Security）・多段のトランザクションが不要
- 単一ノード運用で成立する: 「1台落ちたら復旧する」で許される範囲
ポイントは「安いから」ではなく、「要件がシンプルなら、余計な構造を持ち込まずに安く済む」です。
❌ 向かないケース
- 水平スケールが必須: 早期から複数台でさばきたい、HA（高可用性）が要件
- PostgreSQL機能に依存: 複雑なJOIN、ビュー、関数、拡張、厳密なトランザクション設計が前提
- エンタープライズ要件: 監査、権限、SLO/SLA、組織運用、コンプライアンス要件が強い
- データの整合性を強く求める高更新ワークロード: SQLiteの特性（単一ライタ等）で設計が苦しくなる
実例: なんでも解説動画ジェネレーターでの採用理由
なんでも解説動画ジェネレーター では、PocketBaseを「ジョブキューの管理」にだけ使っています。
やりたいことはだいたいこれだけでした。
- ジョブを作る（queued）
- ワーカーがジョブを取って進める（processing）
- 進捗・結果を更新する（completed / failed）
- UI側は状態変化をリアルタイムに追いたい
Supabaseでももちろん実現できます。ただ、自分のケースでは「DBを賢く使う」より「キューを雑に管理できて、UIが追随すればOK」が優先でした。
採用理由:
- ジョブキュー管理だけなら、SQLite + 単一ノードで十分だった
- UIのリアルタイム更新が欲しかった（PocketBaseの購読で足りた）
- 固定費を抑えたかった（VPS $4〜が現実的）
- 依存コンポーネントが少なく、保守の心理的負担が小さい
アーキテクチャ（ざっくり）:
flowchart LR U[User] --> W[Web UI] W -->|Create job| API[App API] API --> PB[(PocketBase SQLite)] Worker[Worker] -->|Fetch queued jobs| PB Worker -->|Update status/progress| PB PB -->|Realtime subscription| W Worker --> Gen[Video generation LLM/TTS/Render] Gen --> Store[(Object Storage or local files)] Worker -->|Store result URL| PB
この構成だと、PocketBaseは「ジョブ状態の単一ソース」と「UI更新の通知役」に集中できます。逆に言うと、ここがスケール要件に当たった瞬間が、移行を考えるタイミングです。
移行の現実性
Supabase → PocketBase
現実的には「移し替え」というより「作り直し」に近いです。
- PostgreSQL前提のスキーマ（複雑な正規化、ビュー、関数など）は再設計が必要
- RLSを多用している場合、PocketBase側の権限モデルに合わせて組み直しになります
- Supabase Auth前提のトークン設計をしていると、クライアント側の改修も出ます
PocketBase → Supabase
成長したら移行可能です。やることが明確なので、先に「出口」を意識しておくと安心です。
- PocketBaseのコレクションを、後でPostgreSQLに落とせる形（過度にネストしない、ID設計を安定させる）にしておく
- ファイルは最初から外部ストレージに寄せる（移行の痛みを減らす）
- バックアップは Litestream などでSQLiteのレプリケーションを検討しておく
- 認証まわりは"差し替える前提"で、アプリ層に寄せておく
PocketBaseは「小さく始める」には強いですが、長期のスケール戦略まで全部任せるタイプではない、という前提で設計しておくのが安全です。
まとめ
- PocketBaseは「Supabaseの代替」ではなく「別の選択肢」です
- コスト重視 + 要件がシンプル（単一ノードで成立）ならPocketBaseがハマります
- スケール + PostgreSQL機能 + 組織要件ならSupabaseが強いです
- どちらも良いので、先に要件（可用性、運用体制、SQL依存度）を言語化してから選ぶのが一番効きます