Supabase：Postgresベースのオープンソース Firebase代替

背景と概要

Supabaseとは何で、なぜFirebaseへの回答として登場したのでしょうか。SupabaseはPostgresを中核とするオープンソースの開発プラットフォームで、エンタープライズ級のオープンソースツールを使ってFirebaseのような開発体験を再現します。この十年ほどで、モバイルアプリやWebアプリのバックエンドは、データベース、ユーザーログイン、ファイルストレージ、リアルタイム通知、サーバー側関数という固定的な組み合わせに落ち着いてきました。Firebaseはこの一式をマネージドサービスとして提供し、フロントエンド開発者がほとんどサーバーに触れずに製品を公開できるようにしました。その代償として、データモデルは独自仕様の中に閉じ込められ、移行やセルフホストが難しくなります。

Supabaseはこの課題から出発しています。方針は明快です。MITやApache 2など寛容なライセンスの既存ツールがあれば、それを採用して支援します。存在しなければ、自分たちで作ってオープンソースにします。そのためSupabaseはFirebaseの一対一の複製ではなく、成熟したオープンソース部品を一つの製品に組み上げたプラットフォームです。

中核は専用のPostgresデータベースです。このオブジェクトリレーショナルデータベースは30年以上の継続的な開発の歴史を持ち、信頼性、機能の充実度、性能で定評があります。その周囲に、マネージドPostgres、認証・認可、自動生成API、関数、ファイルストレージ、AI向けベクトルツールキット、管理画面が並びます。GitHubのリポジトリは11万を超えるスターを集め、主にTypeScriptで書かれています。トピックにはai、auth、database、deno、embeddings、firebaseが並び、Firebase代替とAIアプリのデータ層という二つの役割を同時に担っていることが分かります。

深掘り分析

Supabaseの技術的な価値は、部品の組み合わせ方にあります。土台はPostgresで、データも権限も最終的にここに集まります。PostgRESTはPostgresデータベースをそのままRESTful APIに変えるWebサーバーです。テーブルを作れば、エンドポイントも自動的に現れ、作成・取得・更新・削除のコードを手書きする必要がありません。PostgreSQL拡張のpg_graphqlは同じデータにGraphQLの入口を加え、チームは好みのクエリ方式を選べます。 SupabaseはPostgresのリアルタイム更新をどう実現しているのでしょうか。RealtimeはElixirで書かれたサーバーで、websocket経由でPostgresの挿入・更新・削除を監視します。Postgres組み込みのレプリケーション機能から変更を読み取り、JSONに変換して、権限を持つクライアントに配信します。データベースを唯一の情報源に保ち、リアルタイム層はデータベースで起きたことを伝えるだけの役割にとどまります。 認証はGoTrueが担当します。JWTベースの認証APIで、ユーザー登録、ログイン、セッション管理を扱います。StorageはS3のファイルを管理するRESTful APIで、権限の判断はPostgresに任せます。そのため、ファイルとデータ行が同じ認可ロジックを共有できます。関数にはデータベース関数とEdge Functionsの二種類があり、リポジトリのdenoというタグはEdge FunctionsとDenoランタイムの関係を示唆しています。ベクトル・埋め込みツールキットにより、Postgresはリレーショナルデータと埋め込みを同じ場所に保存できます。

Firebaseとの最大の違いは土台です。Firebaseは独自のドキュメントデータベースですが、Supabaseは標準SQLとオープンな部品で構成されます。各部品を個別に検査し、入れ替え、理解できる点が、このプロジェクトにおける「ロックインなし」の実質的な意味です。 始め方は三通りあります。最も手軽なのはホスト版で、ダッシュボードで登録すれば何もインストールせずに使い始められます。より多くの制御を求めるチームは、公式のセルフホストガイドに沿ってデプロイできます。ローカルに開発環境を作り、データベース、認証、ストレージを自分のマシンで動かすことも可能です。典型的な流れは、まずPostgresでテーブルを設計し、REST、GraphQL、リアルタイムの各インターフェースを自動生成させ、フロントエンドから直接呼び出すというものです。ログインとファイルアップロードは組み込みの認証とストレージに任せ、独自のロジックはデータベース関数かEdge Functionsに書きます。 ドキュメントはsupabase.com/docsにあり、データベース、認証、API、GraphQL、リアルタイム、関数、ストレージ、AIのガイドに分かれています。コミュニティの窓口も役割が分かれています。GitHub Discussionsはビルドの質問やデータベースのベストプラクティス、GitHub Issuesは不具合報告、メールサポートはデータベースやインフラの問題、Discordは作品の共有です。貢献したい人はDEVELOPERS.mdから読み始められます。

業界への影響

エンジニアリングチームにとって、Supabaseは「素早い立ち上げ」と「ロックインの回避」を一つの提案にまとめています。中心にPostgresがあるため、スキーマ、クエリ言語、権限モデルはどれも業界共通の知識です。今日身につけた経験は、将来別のインフラに移っても役立ちます。書き直しの余裕がない小規模チームにとって、これはベンダーリスクへの現実的な備えになります。

AIの観点も重要です。ベクトルと埋め込みをリレーショナルデータベースに置くことで、小さなチームでも少ないシステムでプロトタイプから公開まで進められます。ユーザーテーブル、権限ルール、埋め込みが一つのデータベースに収まるので、主ストアと別のベクトルサービスとの同期問題を避けられます。

一方で、限界もあります。Supabaseは複数の独立したオープンソース部品から作られたプラットフォームです。セルフホストするチームはそれらを理解して運用する必要があり、その負担はチームの規模や経験で変わります。また、Firebaseの一対一の対応ではないと明言されているため、Firebaseから移行するチームはデータモデリングと権限設計を考え直し、Postgres自体も丁寧に学ぶ必要があります。ホスト版に頼るか、オープンソース部品を自前で動かすかは、コスト、コンプライアンス、運用力を踏まえて判断すべきです。

今後の展望

注目点はいくつかあります。第一に、AIとベクトルのツールキットが、より大規模な実運用で通用するかどうかです。READMEはこれを中核機能として位置づけていますが、元の資料にベンチマークの数値はありません。規模に関する判断は、各チームが自ら検証する必要があります。

第二に、Edge Functionsの開発体験がどう進化するかです。独自ロジックがデータベースの外へ出る場所が関数であり、Denoランタイムとの関係は、TypeScript開発者にとってこの段階がどれだけ滑らかになるかを左右します。

第三に、コミュニティの拡大とともに、このオープンソースの組み合わせが部品間の協調と安定を保てるかどうかです。PostgREST、GoTrue、Realtime、pg_graphqlは別々の部品であり、プラットフォームの価値はそれらが足並みをそろえて進むことにかかっています。GitHubで11万を超えるスターを持ち、DiscussionsやIssues、Discordで活発なやり取りがあるSupabaseには、その約束を試す大きな利用者層があります。独自プラットフォームに縛られずにWeb、モバイル、AIアプリのバックエンドを作りたい開発者にとって、現実的な第一歩はシンプルです。ホスト版で始め、スキーマを標準SQLに保ち、セルフホストは後回しにせず検証済みの選択肢として扱うことです。