Supabase は Postgres を中心に API と認証を束ねる開発基盤
Web、モバイル、AIアプリケーション向けのPostgres開発プラットフォーム。
ひと目でわかる
- これは何？
- supabase/supabase の README から、Postgres を中心にした構成、クライアントの分割、ホスト型とセルフホスト型の入口、ライセンスを読み解きます。
- 誰に向いている？
- Supabase は、Postgres のデータモデルを軸に認証、API、ファイル、リアルタイム通信を一つの開発面で扱いたいチームに向きます。ホスト型で始めるか、セルフホストやローカル開発へ進むかを先に決め、権限、データ所在、バックアップ、費用、各クライアントの機能範囲を公式ドキュメントで確認してください。
- 商用利用できる？
- できます。Apache-2.0 は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。直近 1 日以内に新しいコミットがあります。
- 何の言語で書かれている？
- 主に TypeScript です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
Firebase の写像ではなく Postgres の開発体験
Supabase の README は、Web、モバイル、AI アプリケーション向けの Postgres 開発プラットフォームと自らを説明しています。オープンソースの構成要素を組み合わせ、Firebase に似た開発者体験を作ることが方向性ですが、Firebase の一対一の複製ではないとも明記されています。評価の出発点は、認証や自動 API だけを見ることではなく、Postgres のスキーマ、権限、拡張機能をアプリケーションの中心に置けるかです。リポジトリの主要言語は TypeScript、ホームページは supabase.com です。
README の機能表を実装責任に読み替える
README のチェック項目は、ホスト型 Postgres、認証と認可、自動生成 API、データベース関数と Edge Functions、ファイル Storage、AI とベクトルまたは埋め込みのツールキット、Dashboard です。API の項目には REST、GraphQL、リアルタイム購読が含まれます。これはプラットフォーム自身が示す範囲の一覧で、各機能の既定設定や上限を説明する設計書ではありません。特に AI ツールキットの内部構成と Dashboard の細かな権限は README だけでは分からないため、導入前に対応する公式ドキュメントへ移る必要があります。
Realtime と PostgREST がデータを外へ出す
構成要素の説明では、Postgres がデータベースの土台になります。Realtime は Elixir 製のサーバーで、PostgreSQL の insert、update、delete を監視し、組み込みレプリケーションから変更を取り出して JSON に変え、認可されたクライアントへ WebSocket で配信します。PostgREST はデータベースを RESTful API として公開します。GoTrue は JWT ベースの認証 API、Storage は S3 のファイルを扱う REST API で、権限を Postgres が処理します。pg_graphql、postgres-meta、Envoy も構成部品として列挙されていますが、負荷や障害時の数値は素材にありません。
クライアント表は対応範囲の差を示す
公式クライアントは JavaScript と TypeScript の supabase-js、Flutter の supabase-flutter、Swift の supabase-swift、Python の supabase-py です。コミュニティ側には C#、Go、Java、Kotlin、Ruby、Rust、Godot Engine 向けの名前が表に並びます。機能クライアントも分かれており、JavaScript 系では postgrest-js、auth-js、realtime-js、storage-js、functions-js が例示されています。言語名が表にあることは、すべての機能が同じ水準で実装される意味ではありません。Go と Java には完全な Supabase クライアントが示されず、Rust は postgrest-rs のみが記載されるため、必要な機能を個別に照合する必要があります。
ホスト型からセルフホストへ移る入口
README が示す最短の入口は、Dashboard でサインアップしてインストールなしにホスト型を使う方法です。同じページからセルフホストとローカル開発のドキュメントへ進めますが、README 本文にはセルフホスト用のコマンドや環境変数表はありません。完全な手順は supabase.com/docs、貢献手順は別の DEVELOPERS.md に置かれています。この差は小さく見えて、データ所在地、更新責任、バックアップ、認証情報の保管場所を誰が持つかに直結します。まず学習用途ならホスト型、制御要件が明確ならセルフホストの要件表を先に作るのが安全です。
サポート経路と Apache-2.0 の範囲
README は用途の違う四つの連絡先を案内しています。GitHub Discussions は構築やデータベースの相談、Issues はバグやエラー、メールサポートはデータベースやインフラの問題、Discord はアプリケーション共有と会話向けです。リポジトリは Apache-2.0 で、複製、派生物、公開、サブライセンス、配布に関する著作権許諾と、条件付きの特許許諾が示されています。ライセンスはサポート水準、可用性、セキュリティ監査を約束しません。現在の星、fork、issue の数字も、品質や運用費用を直接証明するものではありません。
Supabase を比較するときは、機能の数よりもデータベースの権限モデルを中心に設計を読むべきです。自動生成 API、Realtime、Storage、Functions が同じデータに触れるため、認証済みユーザー、サービスロール、管理者のそれぞれが何を読めるかをテーブル単位と操作単位で確認します。README は Postgres のレプリケーションから変更を取り出し、認可されたクライアントへ配信する流れを説明しますが、障害時の再送、順序、保持期間、リージョン間の挙動は書いていません。公式クライアントの表も、ライブラリ名と機能の対応を示す資料であって、同じ API が全言語で同じ速度や成熟度を持つ証拠ではありません。ホスト型からセルフホスト型へ移る場合は、Dashboard の操作、SQL の migration、バックアップの復元、秘密鍵の更新を別々の手順として作る必要があります。
アプリケーションの試作では、テーブルを作る前に認証済みユーザーとサービス側の役割を分け、API、Storage、Realtime が同じポリシーをどう参照するかを記録します。Supabase の機能一覧は一つの入口を提供しますが、Postgres の権限設定を省略して安全になるわけではありません。Realtime の購読は認可されたクライアントへ変更を配信する説明になっているため、どの行が購読対象になるかをデータ分類とともに検証する必要があります。セルフホストへ移る場合は、コンポーネントの版、SQL の適用順、バックアップの復元、Dashboard の管理者権限を同じ runbook にまとめます。コミュニティ、Issues、メール、Discord は相談経路ですが、問い合わせ先の存在は障害対応の時間や SLA を意味しません。Apache-2.0 もこの点を補いません。
編集部の結論
Supabase は、Postgres のデータモデルを軸に認証、API、ファイル、リアルタイム通信を一つの開発面で扱いたいチームに向きます。ホスト型で始めるか、セルフホストやローカル開発へ進むかを先に決め、権限、データ所在、バックアップ、費用、各クライアントの機能範囲を公式ドキュメントで確認してください。README の機能一覧だけでは運用条件やセキュリティ評価は完結しません。
コミュニティノート