Firebase代替のBaaSにSupabaseが選ばれる理由

「Firebaseの代替を探している」という出発点でSupabaseにたどり着いたものの、そこから先の判断で止まってしまうことがあります。日本語の情報は機能一覧、Firebaseとの対応表、無料枠の紹介に集中しており、どれを読んでも「よさそうだ」以上の結論が出てきません。

比較が難しいのには理由があります。BaaSはどれも認証・データベース・ストレージ・リアルタイム更新・サーバーレス関数を揃えており、機能を並べるとほぼ同じ表になります。差が出るのは機能の有無ではなく、その機能をどこに置いているか、つまり設計思想の側です。そしてその差は、採用したあとの設計やコストに効いてきます。

Supabaseの場合、その分岐点はきわめてはっきりしています。Postgresを隠さず、そのまま使わせるという一点です。APIはデータベーススキーマから自動生成され、認可はアプリケーション層ではなくデータベース層の行レベルセキュリティ（RLS）に置かれます。この設計を受け入れられるかどうかが、そのまま採用可否の判断軸になります。

本記事では、Supabaseのリポジトリ構成、アーキテクチャと公式が掲げる設計原則、RLSを前提とした認可設計の注意点、ホステッドとセルフホストの違い、そしてPocketBase・Appwrite・Nhostとの差分を、Supabase のREADMEと公式ドキュメントに基づいて整理します。動作検証やインストールは行っておらず、記述はすべて公開ドキュメントとGitHub APIで取得した公開値の読解に基づくものです。数値は2026年9月28日時点の取得値です。

Supabaseとは｜Postgresを中核に据えたOSSのバックエンド基盤

Supabaseは、READMEの冒頭で自身を次のように定義しています。

Supabase is the Postgres development platform. We're building the features of Firebase using enterprise-grade open source tools.

（出典: supabase/supabase README）

「Firebaseの機能を、エンタープライズグレードのオープンソースツールで作る」という表現がそのまま性格を表しています。独自エンジンを一から作るのではなく、既存のOSS（Postgres、PostgREST、Denoなど）を組み合わせてFirebase相当の機能群を構成する、という方針です。

リポジトリ基本情報

gh api /repos/supabase/supabase で取得した公開値は次のとおりです。

いずれも2026年9月28日時点の値です。リリースは月次の「Developer Update」形式で発行されており、直近は v1.26.08（2026年8月7日）、その前が v1.26.07（2026年7月9日）です。最終pushが取得日の前日、リリースが月次で継続していることから、メンテナンスの継続性という観点では健全な部類に入ると判断できます。ライセンスがApache-2.0である点も、商用利用を含めた採用判断では扱いやすい条件です。

提供機能の全体像

READMEが挙げる機能は次のとおりで、各項目に公式ドキュメントへのリンクが張られています。

• ホスト型のPostgresデータベース
• 認証・認可
• 自動生成API（REST、GraphQL、リアルタイムサブスクリプション）
• 関数（データベース関数、Edge Functions）
• ファイルストレージ
• AI・ベクトル / 埋め込みツールキット
• ダッシュボード

ここで注意しておきたいのは、READMEが同時に「Supabase is not a 1-to-1 mapping of Firebase.」と明記していることです。機能カテゴリの並びはFirebaseに似ていますが、個々の機能をFirebaseの機能に1対1で読み替えることは公式に否定されています。Firebaseからの移行を前提に読むと、この前提のずれがあとで効いてきます。

supabase/supabaseリポジトリの中身とコアサービスの関係

11万を超えるスターが付いていると、つい「Supabaseという単一のエンジンがそれだけ評価されている」と読んでしまいがちですが、リポジトリの中身を見ると実態は異なります。

モノレポに含まれるもの

supabase/supabase のルートには apps/、blocks/、docker/、e2e/、examples/、i18n/、packages/、patches/、scripts/、supabase/ などが並びます。apps/ の内訳は studio（管理ダッシュボード）、lite-studio、docs（公式ドキュメント）、www（公式サイト）、kb、learn、design-system、ui-library です。

つまりこのリポジトリはプラットフォーム全体のモノレポであり、中心を占めているのはStudio・公式ドキュメント・公式サイト・サンプル・セルフホスト用のDocker構成です。データベース周辺のコアサービスそのものは、ここには含まれていません。

別リポジトリで開発されるコアサービス

READMEの「How it works」が示すとおり、実際のバックエンド機能は独立したリポジトリ・プロジェクトで開発されています。

この構造は、採用検討の実務にそのまま影響します。認証の挙動を深く追いたいならGoTrueのリポジトリを、REST APIの生成ルールを確認したいならPostgRESTのドキュメントを読む必要があり、Issueを立てる先も機能ごとに変わります。フォークして手を入れる可能性を見積もるときも、対象は supabase/supabase ではなく個別リポジトリになります。「どこを読むべきか」を先に把握しておくと、調査コストの見積もり精度が上がります。

なお、クライアントライブラリは公式提供がJavaScript/TypeScript、Flutter、Swift、Pythonの4つで、C#・Go・Java・Kotlin・Ruby・Rust・Godot（GDScript）はコミュニティ提供です。コミュニティ提供のものは言語によってAuthのみ、Storageのみといったカバー範囲のばらつきがあり、READMEの対応表でも統合クライアントが未提供の言語があります。採用言語が公式4言語から外れる場合は、この対応状況を先に確認しておく必要があります。

Supabaseのアーキテクチャと「Postgresを抽象化しない」設計原則

公式のアーキテクチャドキュメントは、Postgresを中心に複数のサービスを配置した構成を示しています。

構成要素とリクエストの流れ

Postgresに接続される主なサービスは、GoTrue（認証）、PostgREST（REST API）、Realtime（リアルタイム・マルチプレイヤー）、Storage（大容量ファイル）、pg_meta（データベース管理）、Functions（Denoベースのエッジ関数）、pg_graphql（GraphQL API）の7つです。これらの前段にEnvoyがAPIゲートウェイとして立ち、加えてSupavisor（コネクションプーラー）とStudio（ダッシュボード）が構成に含まれます。

クライアントからのリクエストはEnvoyを経由して各サービスに振り分けられ、最終的にはいずれもPostgresに到達します。認証もストレージのメタデータも、実体はPostgresのテーブルとして存在します。

公式が掲げる設計原則のうち採用判断に効く3つ

公式は7つの設計原則を挙げています。採用判断の観点では、そのうち次の3つが実務に直結します。

Everything works in isolation（すべてが単体で機能する）。各サービスは最小限の依存で単体のツールとして成立するよう設計されています。実務上は、必要な機能だけを使い、不要な機能を無視できることを意味します。認証だけをSupabaseに任せる、あるいはデータベースだけを使う、といった段階的な採用がしやすくなります。

Everything is extensible（すべてが拡張可能）。新しいツールを作るより既存ツールを拡張することを優先する方針です。これがPostgres拡張（pg_graphql、pgvector、PostGISなど）を積極的に取り込む姿勢につながっており、Postgresエコシステムの資産をそのまま持ち込めます。

Everything is portable（すべてが可搬）。クラウド版とセルフホスト版の互換性を保ち、出入りの移行を容易にするという原則です。「BaaSに載せるとロックインされるのではないか」という懸念に対する公式の回答がここにあたります。ただし後述のとおり、セルフホストでは使えないマネージド機能が具体的に存在するため、この原則を額面どおりに受け取るのではなく、欠ける機能を確認したうえで判断する必要があります。

そして、これらの原則の土台になっているのが次の一文です。

We do not abstract the Postgres database—you can access it and use it with full privileges.

（出典: Supabase Architecture）

Postgresを抽象化せず、フル権限でアクセスできる状態にしておく。これはメリットとして語られることが多い記述ですが、同時に「データベースの設計責任がそのまま利用者側に残る」ことも意味します。次に見る認可設計は、その具体例です。

自動生成APIを使うときの認可設計｜RLSを前提にする

Supabaseを採用するうえで、最初に理解しておくべき設計上の前提がRLS（Row Level Security、行レベルセキュリティ）です。ここは公式ドキュメントでも強い調子で警告されている箇所です。

なぜRLSが前提になるのか

SupabaseのREST APIは、データベーススキーマから自動生成されます。テーブルを作れば、そのテーブルにアクセスするエンドポイントが自動的に生えるということです。開発速度の面では大きな利点ですが、裏を返すと、公開スキーマに置いたテーブルは何も設定しなければAPI経由で読み書きできてしまいます。公式ドキュメントの記述は次のとおりです。

A table in an exposed schema without RLS is readable and writable by any role with a grant on it.

（出典: Row Level Security）

一般的なWebアプリケーションでは、認可はアプリケーションサーバーのコードに書きます。SupabaseではAPIサーバーが自動生成されるため、そこに認可ロジックを差し込む場所がありません。そのため認可の責任はデータベース層、つまりRLSポリシーに移ります。アーキテクチャドキュメントがGoTrueについて「Postgresの行レベルセキュリティおよびAPIサーバーと統合される」と説明しているのも、この設計を指しています。

ポリシーの書き方とauth.uid()

RLSは2段構えで理解すると整理しやすくなります。grant（そのロールがそのテーブルに対してどの操作をできるか）と、ポリシー（その操作が対象にできる行はどれか）です。ポリシーは、すべてのクエリに自動で付与されるWHERE句のように働きます。

公式ドキュメントが示すポリシーの例は次のとおりです。

create policy "Individuals can view their own todos."
on todos for select
to authenticated
using ( (select auth.uid()) = user_id );

（出典: Row Level Security）

auth.uid() は現在リクエストしているユーザーのIDを返すヘルパー関数で、未認証の場合はnullになります。このポリシーは「認証済みロールがtodosテーブルをselectするとき、user_id が自分のIDと一致する行だけを見せる」という意味です。似たヘルパーに auth.jwt() があり、JWTのクレーム（raw_app_meta_data など）を参照してロールベースの判定を書くこともできます。

認可の記述がSQLになるため、アプリケーションコードのレビューだけでは認可の妥当性を検証できなくなります。マイグレーションやポリシーの変更をレビュー対象に含める運用が前提になる、という点は採用時に見込んでおく必要があります。

見落としやすい注意点

公式ドキュメントが挙げている注意点のうち、設計に影響が大きいものが2つあります。

1つは、ポリシーを追加しただけでは既存のgrantは消えないという点です。公開スキーマのテーブルはすべてRLSを有効化したうえで、不要なgrantを明示的にrevokeする必要があります。「ポリシーを書いたから安全」という理解で止まると、grant側が開いたままになります。

もう1つはビューの扱いです。postgres ユーザーが作成したビューは自動的に security definer として扱われ、既定でRLSの保護をバイパスします。ビューを安全に公開するにはPostgres 15以降で security_invoker = true を使うか、それ以前のバージョンではアクセス自体を制限する必要があります。集計用のビューを何気なく作って公開スキーマに置くと、RLSを有効にした意味がなくなる、という事故が起きうる箇所です。

この領域はSupabase固有というよりPostgresの知識そのものです。SQLとPostgresの権限モデルに踏み込む前提を受け入れられるかどうかが、Supabaseを選ぶかどうかの実質的な分かれ目になります。認証側の設定や各プロバイダーの扱いについてはAuth のドキュメントが入口になります。

ホステッド・セルフホスト・ローカル開発の使い分け

Supabaseには3つの使い方があり、それぞれ提供される機能と運用責任が異なります。ここを混同すると、コスト見積もりも移行計画もずれます。

ホステッドの料金と無料枠の実際

公式の料金ページが示すプランは次のとおりです。

Freeプランで注意すべき制約は2つ明記されています。1週間アクティビティがないとプロジェクトが一時停止されること、そしてアクティブなプロジェクトは2つまでという上限です。検証用と本番用を並行させたい、あるいは間欠的にしか触らないプロジェクトを置いておきたい、といった使い方はFreeの範囲では成立しません。

また、Pro / Teamのベース価格にはCompute（データベースのインスタンスサイズ）としてMicroが含まれ、そこから上のサイズはアドオンとして加算されます。Micro $10（共有CPU・1GB RAM）、Small $15（共有・2GB RAM）、Large $110（専有2vCPU・8GB RAM）、XL $210（専有4vCPU・16GB RAM）といった刻みで、上位は16XLの$3,730まで用意されています。月$25という数字だけで見積もると、必要なコンピュートサイズが上がった時点で実際のコストとの乖離が大きくなります。

セルフホストで手に入るもの・失うもの

セルフホスティングのドキュメントは「The fastest and recommended way to self-host Supabase is to use Docker.」として、Dockerによる構成を公式の推奨としています。コミュニティ製のKubernetes（Helm）構成やTraefik構成も存在します。

重要なのは、セルフホストでは利用できないマネージド機能が具体的に列挙されていることです。

• ブランチング
• 高度なメトリクス（ログを超える範囲）
• マネージドバックアップとPITR（ポイントインタイムリカバリ）
• Analytics、ベクトルバケット
• ETL
• プラットフォーム管理API

PITR付きのマネージドバックアップが使えない点は、本番運用の要件によっては決定的な制約になります。「セルフホストすれば同じものが無料で手に入る」という理解は正確ではなく、バックアップとリカバリの仕組みは自前で用意する前提になります。

運用責任の範囲も明示されています。公式が挙げるのは、サーバーのプロビジョニングと保守、セキュリティハードニングとOS・各サービスの更新、サービスの設定と管理、Postgresのメンテナンス、高可用性とスケーラビリティ、バックアップと災害復旧、監視とアップタイムです。サポートもGitHub Discussions・GitHub Issues・Discord・Redditといったコミュニティベースに限られます。これらを担える体制があるかどうかが、セルフホストを選べるかどうかの条件になります。

なお、セルフホストのDockerインスタンスはテレメトリを送信しないと明記されています。データを外部に出せない要件がある場合には、この点が採用理由になり得ます。

CLIによるローカル開発の位置づけ

3つ目がCLIによるローカル開発環境です。ローカル開発のドキュメントによれば、supabase init でプロジェクトを初期化し、supabase start でローカルスタックを起動します。Docker互換のコンテナランタイム（Docker Desktop、Rancher Desktop、Podman、OrbStackなど）が必要で、起動後は http://localhost:54323 でローカルのStudioにアクセスできます。CLIはマイグレーションと宣言的スキーマの管理、Supabaseプラットフォームへのデプロイにも対応しています。

ここで混同しやすいのが、ローカルスタックとセルフホスト本番は別物だという点です。公式はローカルスタックについて、本番向けにハードニングされておらず、外部トラフィックに晒してはならないと明記しています。ローカルで動いた構成をそのまま公開サーバーに置く、という進め方はできません。

3つの位置づけを整理すると、開発と検証はCLIのローカルスタック、本番の第一選択はホステッド、データ主権や特殊な要件がありかつ運用体制を確保できる場合にセルフホスト、という並びになります。

PocketBase・Appwrite・NhostとSupabaseの違い

Firebase代替を探す過程では、Supabase以外にも複数のOSSが候補に挙がります。主要なものを横並びにすると、それぞれの狙いの違いが見えてきます。

類似OSS5件とSupabaseの横並び比較

数値は2026年9月28日時点にGitHub APIで取得した公開値です。

directus/directus のライセンスがGitHub API上で NOASSERTION と返る点には注意が必要です。標準的なOSSライセンス識別子に自動判定されていないことを意味するため、採用検討時にはリポジトリのライセンス条文を直接確認する必要があります。

選択が分かれる3つの分岐点

比較表を眺めるより、判断が分かれる軸を3つに絞ったほうが実務では役に立ちます。

データモデル。Supabase・Nhost・DirectusはPostgres前提、PocketBaseはSQLiteを同梱、AppwriteはMariaDBベース、Parse ServerはMongoDBまたはPostgresから選択します。リレーショナルな設計を前提にしていて、既存のSQL資産やPostgres拡張（pgvector、PostGISなど）を活かしたいのであれば、Postgres系が候補になります。逆にデータ構造がシンプルで単一サーバーに収まるなら、SQLite同梱のPocketBaseのほうが構成は軽くなります。

配布・運用形態。PocketBaseは単一バイナリ1ファイルという軽さが特徴で、セルフホストの運用負荷が最小です。Supabaseは複数サービスの組み合わせであり、セルフホストはDocker前提になります。一方でSupabaseにはマネージドのクラウド版があり、運用を持たない選択肢も取れます。「まずマネージドで始めて、必要になったらセルフホストへ」という段階的な移行余地を残したい場合、この差は大きく効きます。

認可の置き場所。ここがSupabaseの最も特徴的な点です。SupabaseはPostgresのRLS、つまりデータベース層に認可を置きます。AppwriteやPocketBaseはアプリケーション層の権限ルールとして表現します。SQLで認可を記述することに抵抗がなく、むしろ「どのクライアントから来ても同じルールが効く」ことを利点と感じるならSupabaseが合います。逆に認可をアプリケーションコード側で完結させたいチームには、この設計は摩擦になります。

Firebaseとの関係については、README自身が「Supabase is not a 1-to-1 mapping of Firebase.」と述べているとおり、機能単位の置き換え表として捉えるのは適切ではありません。FirestoreのドキュメントモデルとPostgresのリレーショナルモデルは、データ設計の出発点から異なります。Firebaseからの移行を検討する場合は、機能の対応付けではなくデータモデルの再設計として見積もったほうが、実態に近くなります。

Supabaseを選ぶ場合・選ばない場合の判断チェックリスト

ここまでの内容を判断軸に落とすと、次のように整理できます。いずれも公式ドキュメントの記述から導ける条件であり、プロジェクトの前提に照らして確認する項目です。

選びやすいケース

• リレーショナルなデータ設計が前提で、既存のSQL資産やPostgresの知識を活かしたい
• 認証・ストレージ・リアルタイム更新を短期間で揃える必要があり、個別に構築する余裕がない
• 将来のセルフホスト移行の余地を残したい（Portabilityの原則とDockerによるセルフホスト構成が用意されている）
• pgvectorを使ったベクトル検索やAI機能を、アプリケーションデータと同じデータベースに載せたい
• 認可ルールをデータベース層に集約することが、複数クライアント（Web・モバイル・バッチ）を持つ構成で利点になる

慎重に検討すべきケース

• 認可ロジックをアプリケーションコード側に置きたい、あるいはSQLでの認可記述をレビューできる体制がない
• オフライン優先のモバイルアプリで、クライアント側のローカル永続化と同期が主要な要件になっている
• セルフホストが必須で、かつPITR付きのマネージドバックアップや高度なメトリクスが要件に入っている（これらはセルフホストでは提供されません）
• セルフホストを選ぶ場合に、サーバー保守・ハードニング・高可用性・バックアップ・監視を担える運用体制が確保できない
• 採用言語の公式クライアントが提供されていない（公式提供はJavaScript/TypeScript、Flutter、Swift、Pythonの4つ）

判断を保留する場合の進め方

いずれとも決めきれない場合は、段階を踏んで確認する方法があります。まずCLIのローカルスタックでスキーマとRLSポリシーを書いてみて、認可をSQLで表現する設計が自分たちのチームに馴染むかを確かめます。次にFreeプランでプロトタイプを動かし、想定するクエリパターンとデータ量で無理がないかを見ます。本番移行の見積もりを立てる段階で、MAU・エグレス・ストレージに加えて必要なComputeサイズまで含めてコストを算出します。この順序であれば、判断に必要な情報を段階的に集められます。

まとめ

Supabaseは「Postgresを隠さないBaaS」です。この一点が、機能一覧では見えない差の正体であり、採用判断の軸になります。

判断が分かれるポイントは3つに集約できます。1つ目はデータモデルで、リレーショナル設計とPostgresの資産を活かせるかどうか。2つ目は認可の置き場所で、RLSによるデータベース層の認可を設計・レビューできる体制があるかどうか。3つ目はセルフホスト要件で、PITRや高度なメトリクスといった提供されない機能が要件に含まれていないか、そして運用体制を確保できるかどうかです。

またリポジトリの構造として、supabase/supabase はStudio・ドキュメント・公式サイト・Docker構成を中心としたモノレポであり、認証やREST APIといったコアサービスは別リポジトリで開発されています。深く調査する段階では、読むべき場所が機能ごとに分かれることを前提に見積もってください。

次に読むべき公式ドキュメントとしては、構成全体を把握するならアーキテクチャ、認可設計に踏み込むならRow Level Security、運用形態を決めるならセルフホスティングが入口になります。

関連情報

バックエンド基盤の技術選定や、Supabaseを含むOSSを用いたシステム開発をご検討中の場合は、お問い合わせフォーム からご相談いただけます。要件の整理段階からのご相談も承っています。

参考リンク

• supabase/supabase（GitHub リポジトリ・README）
• Supabase 公式サイト
• Supabase Architecture（アーキテクチャと設計原則）
• Row Level Security（RLSポリシーの公式ドキュメント）
• Auth（認証・認可のドキュメント）
• Self-Hosting（セルフホストの制約と運用責任）
• Local Development（CLIによるローカル開発）
• Supabase Pricing（料金プラン）
• AI & Vectors（ベクトル・埋め込みのドキュメント）
• supabase/realtime（Realtime サーバー）
• supabase/gotrue（認証API）
• supabase/storage-api（ストレージAPI）
• supabase/postgres-meta（Postgres管理API）
• PostgREST 公式サイト