先に要点
- 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 です。 「 普通の 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);
なぜ 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 という棲み分けです。 「既存の 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 アプリでは代替になるのが現実的な答えです。「非構造化 + Google エコシステム」 が必須なら Firebase ですが、「SQL を使い続けたい」 ケースでは Supabase の方が自然です。
Q. Supabase はベンダーロックインが心配ないですか？
A. Firebase と比べると圧倒的に少ないです。「PostgreSQL そのもの」 を使っているので、「pg_dump で吸い出して別の Postgres ホスティングに移す」 が物理的に可能。「セルフホスト版」 も公式に提供されています。
Q. Supabase だけでアプリが完結しますか？
A. 小〜中規模なら十分完結するです。「Auth / DB / Storage / Realtime / Edge Functions / Vector」 が揃っているので、「バックエンドを別途書く必要」 はほぼなくなります。スケール時に 「特定機能だけ別基盤に逃がす」 という選択肢もあります。
Q. RLS が複雑そうで心配です。
A. 最初は1テーブル1ポリシーから始めるのが定石です。「auth.uid() = user_id」 のような単純なものから入り、`複雑な権限ロジックは Postgres の関数(「security definer」)に逃がす」 のがチームで運用しやすいです。
Q. Drizzle / Prisma と Supabase は組み合わせられますか？
A. はい、Supabase の Postgres は普通の Postgresなので、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 は触ると一気にわかる」 タイプなので、まず動かしてみるのが近道です。