先に要点
- Supabase は ` PostgreSQL を中心にした、オープンソースの BaaS(Backend as a Service)』。`Firebase の代替』 として有名だが、根本的な違いは ` 普通の SQL と RDB が使える』 こと。
- 提供機能は ` Postgres DB / 認証(Auth)/ ストレージ / Realtime(変更通知)/ Edge Functions / Vector(ベクトル検索)/ Cron / Queues』 など、`バックエンドに欲しい一通り』 がオールインワンで揃う。
- 強みは ` Postgres そのものを使える』 こと。Drizzle / Prisma などの普通の ORM や、`Row Level Security』 でアプリ層の認可ロジックを DB に寄せられるのが特徴。
- 制約は ` 基本は Postgres ベースのため、Firebase の `何でも非構造化』 的な柔軟さは持たない』。`SQL を書ける / 書きたいか』 が向き不向きの分水嶺になる。
Supabase ってよく聞くけど、Firebase と何が違うの？ 自分で Postgres を建てるのと比べて何が嬉しい？ 認証や Storage まで入っているって本当？』 ── 2020 年に登場した Supabase は、OSS な Firebase 代替』 として急速に存在感を増し、2026 年現在は中小規模スタートアップから個人開発まで広く採用されています。
ざっくり言うと、Supabase は PostgreSQL を中心に、Web / モバイル開発で必要なバックエンド機能をオールインワンで提供する BaaS』</strong> です。 普通の Postgres』 がそのまま使えるため、`Drizzle / Prisma / 生 SQL のどれでもアクセスできる』 という柔軟さが Firebase との大きな違いになります。
この記事では、2026 年 5 月時点の Supabase をベースに、提供機能・Firebase との比較・採用判断・落とし穴 を整理します。 仕様は活発に変化しているので、最終確認は 公式ドキュメント を見るのが安全です。
Supabase が提供する機能
Supabase の主要機能を1枚で見渡すと、`バックエンドに欲しいもの一式』 が揃っているのが分かります。
| 機能 | 中身 | 代表用途 |
|---|---|---|
| Postgres DB | 普通の PostgreSQL(拡張多数) | 業務データ全般 |
| Auth | メール / OAuth / Magic Link / Passkey / MFA | ユーザー認証 + RLS と統合 |
| Storage | S3 互換オブジェクトストレージ | 画像 / 動画 / PDF / 添付ファイル |
| Realtime | 変更通知 + Broadcast + Presence | 共同編集 / チャット / カウンタ |
| Edge Functions | Deno 製のサーバレス | 外部 API 連携 / Webhook |
| Vector(pgvector) | ベクトル検索拡張 | RAG / 類似検索 / レコメンド |
| Cron / Queues | 定期実行 + メッセージキュー | 定期バッチ / 非同期処理 |
| Studio | ブラウザ UI(テーブル / SQL / Auth 管理) | 運用 / 確認 |
Postgres + 認証 + Storage + Realtime + Edge Functions』 の組み合わせが、小〜中規模 SaaS なら Supabase だけで完結する』 と言われる根拠です。
仕組みの肝 — Row Level Security(RLS)
Supabase の最大の特徴は、`認可ロジックを DB の Row Level Security(RLS)に寄せる』 設計です。
-- 自分の投稿だけ読める / 書ける
create policy "Users can read own posts"
on posts for select
using (auth.uid() = user_id);
create policy "Users can insert own posts"
on posts for insert
with check (auth.uid() = user_id);
RLS とは
PostgreSQL 標準の機能で、` 行単位でアクセス制御』を SQL でかける仕組み。`このユーザーはこの行を読める / 書ける / 削除できる』 を ポリシーとして書く。
なぜ Supabase で重要か
Supabase は ` クライアントから直接 DB に SQL を投げる』 のが基本構造。`API サーバを書かなくていい』 代わりに、`認可は DB 側で確実にかける』 必要がある。RLS がその要。
`auth.uid()』
Supabase Auth で認証済みのユーザー ID を返す関数。`このユーザーが見える行はどれか』 を書くときの主役。
`認可ロジックを DB レベルで一元管理』 する設計は、Supabase で開発するときの一番大きな思想転換になります。
基本の書き方 — クライアントから DB へ直接アクセス
最小例で雰囲気をつかみます。
import { createClient } from '@supabase/supabase-js';
const supabase = createClient(SUPABASE_URL, SUPABASE_ANON_KEY);
// 取得
const { data: posts } = await supabase
.from('posts')
.select('*')
.eq('user_id', userId);
// 挿入
const { data: newPost } = await supabase
.from('posts')
.insert({ title: 'こんにちは', body: '初投稿です' })
.select()
.single();
// 認証
const { data: { user } } = await supabase.auth.signInWithPassword({
email,
password,
});
// ストレージ
await supabase.storage
.from('avatars')
.upload(`${user.id}/avatar.png`, file);
直接 SQL も可能
`supabase.rpc('関数名', { args })』 で ` PostgreSQL のストアド関数』 を呼べる。複雑な処理は DB 側に置いて RPC で呼ぶ設計が綺麗。
フレームワーク統合
`@supabase/auth-helpers-nextjs』 などで Next.js / SvelteKit / Remix から自然に使える。`サーバとクライアントで同じ API』 を意識せず使い分けできる。
Realtime 機能
` supabase.channel('posts').on('postgres_changes', ...)』 で行の変更を購読できる。`チャット』 `共同編集』 系の機能が `WebSocket を自分で扱う』 必要なく書ける。
`バックエンドを書かなくても、フロントから DB を直接叩いてアプリができる』 のが Supabase の体験を端的に表す部分です。
Firebase との比較
`Supabase と Firebase、どちらを選ぶ？』 を表で並べます。
| 軸 | Firebase | Supabase |
|---|---|---|
| DB | Firestore(NoSQL)/ Realtime DB | PostgreSQL(SQL) |
| クエリの柔軟さ | 制約あり(複合インデックス必須) | SQL の柔軟さそのまま |
| 認可 | Security Rules(独自 DSL) | Row Level Security(SQL) |
| 認証 | 充実(Firebase Auth) | 充実(Supabase Auth) |
| Realtime | 強い(Realtime DB が本職) | 標準サポート |
| Storage | あり(Cloud Storage) | あり(S3 互換) |
| 関数 / サーバレス | Cloud Functions | Edge Functions(Deno) |
| OSS / セルフホスト | ×(Google 専属) | ○(自前ホスティング可) |
| ベンダーロックイン | 強い | 弱い(Postgres は普通の RDB) |
| 料金感 | 無料枠あり、スケールで増える | 無料枠あり、有料 $25/月から |
要点は 非構造化と Google エコシステムなら Firebase、SQL とロックイン回避なら Supabase』</strong> という棲み分けです。既存の SQL 知識を活かしたい』 `Postgres を使い続けたい』 チームは Supabase が圧倒的に楽です。
いつ Supabase を選ぶか
採用判断の目安を整理します。
向いている
① MVP / スタートアップ初期、② SaaS / Web アプリ全般、③ 個人開発(無料枠が手厚い)、④ AI 連携(`pgvector』 で RAG)、⑤ Postgres 経験がある / これから使いたいチーム。
向かない / 慎重に
① 既に Firebase で大量に動いている案件、② スケーラビリティ要件が極端(数百万 RPS など)、③ 厳密な RDB 設計を回避したい初期 MVP、④ Google エコシステム(GCP)に深く依存する案件。
マネージドかセルフホストか
` まずクラウド版』 が無難。`データ主権 / ロックイン回避 / 大量データ』 の要件が出てから、`セルフホストへ移行可能』 というオプションが効く。
Vercel + Supabase は事実上の定番スタック。`@supabase/ssr』 で RSC や Server Actions と自然に連携する。
`小さく始めて、必要に応じてセルフホストに逃げられる』 安心感が、Supabase を選ぶ大きな理由のひとつです。
どこで詰まりやすいか
便利な反面、現場で踏みやすい注意点もあります。
①RLS の罠
` ポリシーを書き忘れた → 誰でも全部見られる』 系の事故が起きやすい。` テーブルを作ったら必ず enable Row Level Security』 を運用ルールにする。`anon』 ロールで Studio から見えるかをチェック。
② 公開鍵と service_role キー
`anon』 キーはクライアント公開 OK、`service_role』 キーは絶対にクライアントに渡さない。`Edge Functions / サーバ専用』。`誤って GitHub にコミット』 が起きないよう、最初の段取りを丁寧に。
③ Realtime の制限
` 同時接続数』 `1チャネルあたりのメッセージレート』 などプランごとに制限がある。`チャットアプリでスケールしたら有料プランへ』 を最初から見据えておく。
④ 移行ツール
`supabase migration』 で SQL マイグレーション管理できるが、`schema をどこを真実とするか』 はチームで早めに決める(Studio の手動編集 vs CLI 駆動)。
`Supabase は便利だが、RLS と service_role キーの扱いだけは最初に身につける必要がある』 のが現場の声です。
AI 時代の Supabase
AI 連携の文脈で Supabase は強い相性を持ちます。
pgvector でベクトル検索
PostgreSQL 拡張の ` pgvector』 が標準で使える。`埋め込みベクトルを DB に保存 → 類似検索』 という RAG のパイプラインを、Supabase 内で完結できる。
Vercel + Next.js + Supabase 構成
` v0 で UI 生成 → Next.js + RSC → Supabase で DB / Auth / Vector』 が AI 時代の MVP の事実上の定番ルート。
Storage で AI 生成物を保管
` AI が生成した画像 / PDF / 音声』 を `Storage に保存 → 認証付き URL でユーザーに配信』 が自然に書ける。
AI 時代の個人開発 / スタートアップ』 で、Supabase が バックエンドのデフォルト選択肢』 のひとつになっている流れがあります。
Supabase に関するよくある質問
Q. Supabase は本当に Firebase の代替になりますか？
A. 多くの SaaS / Web アプリでは代替になる』</strong>のが現実的な答えです。非構造化 + Google エコシステム』 が必須なら Firebase ですが、`SQL を使い続けたい』 ケースでは Supabase の方が自然です。
Q. Supabase はベンダーロックインが心配ないですか？
A. Firebase と比べると圧倒的に少ない』</strong>です。PostgreSQL そのもの』 を使っているので、pg_dump で吸い出して別の Postgres ホスティングに移す』 が物理的に可能。セルフホスト版』 も公式に提供されています。
Q. Supabase だけでアプリが完結しますか？
A. 小〜中規模なら十分完結する』</strong>です。Auth / DB / Storage / Realtime / Edge Functions / Vector』 が揃っているので、バックエンドを別途書く必要』 はほぼなくなります。スケール時に 特定機能だけ別基盤に逃がす』 という選択肢もあります。
Q. RLS が複雑そうで心配です。
A. 最初は1テーブル1ポリシーから始める』</strong>のが定石です。auth.uid() = user_id』 のような単純なものから入り、複雑な権限ロジックは Postgres の関数(security definer』)に逃がす』 のがチームで運用しやすいです。
Q. Drizzle / Prisma と Supabase は組み合わせられますか？
A. はい、 Supabase の Postgres は普通の Postgres』</strong>なので、Drizzle / Prisma / Kysely などのお気に入りの ORM がそのまま使えます。Supabase SDK は使わず、ORM だけで使う』 という構成も普通にあります。
Q. Supabase の料金体系は？
A. 無料プランは小規模個人開発に十分な範囲、Pro プランは月 $25 で本格的な SaaS スタートに十分。データベース容量 / 帯域 / Auth ユーザー数 / Storage 容量』 の組み合わせで超過分が課金。大規模化したら有料プラン or セルフホスト』 という二段構え。
Q. Supabase 学習の最短ルートは？
A. ① 公式 Quickstart で Next.js + Supabase Auth + DB』 を1時間で動かす、② RLS』 を1テーブルで書いてみる、③ Realtime』 で行変更を購読する、の3段階が王道です。Supabase は触ると一気にわかる』 タイプなので、まず動かしてみるのが近道です。