Supabase 完全入門 - PostgreSQL ベースの BaaS と Firebase との徹底比較（2026年最新版）

Supabase とは

Supabase（スーパベース）は、「オープンソースの Firebase 代替」 を掲げて開発が進む BaaS（Backend as a Service）プラットフォームです。PostgreSQL をコアに据え、その上に認証・ストレージ・リアルタイム・サーバーレス関数といった、アプリ開発で必要な構成要素をひとつにまとめて提供しています。

2020年に登場して以降、開発者数の伸びは右肩上がりで、2026年第1四半期時点では 開発者数120万人超、BaaS 市場シェア 28% にまで拡大したと報じられています（tech-insider.org）。

本記事は 2026年5月7日時点 の Supabase 公式 Changelog／ドキュメントと、Next.js 16 を前提に執筆しています。

Supabase の基本情報

「Postgres を中心に据えていること」が Supabase の最大の特徴で、これは Firebase（NoSQL の Firestore）との根本的な違いを生み出しています。

アーキテクチャ - 「Postgres + 既存OSS + 薄いラッパー」

Supabase はゼロから作った独自基盤 ではなく、業界標準の OSS を組み合わせたアーキテクチャです。これがオープンソースとの親和性とロックインの少なさにつながっています。

「Postgres を本気で使えるなら、その周辺ツールはすべて Supabase が肩代わりしてくれる」という構造で、すべての操作の最終的な裏側は SQL です。これは「Postgres を知っていれば学習コストが極めて低い」というメリットになります。

主要機能を一周する

1. Database（PostgreSQL）

• フル機能の Postgres インスタンスが各プロジェクトに1つ提供
• 一般の Postgres 拡張（pgvector, PostGIS, pg_cron, pg_net など）が利用可能
• REST API と GraphQL API がスキーマから自動生成
• データベース Webhook（変更を任意の外部サービスに送信）
• バックアップ／リードレプリカ／読み取り専用のリージョン分散

ベクトル DB（pgvector）も同居しているので、RAG / 埋め込み検索 のためだけに別ベクトル DB を立てる必要がない、というのも近年の追い風になっています。

2. Auth（認証・認可）

• メール／パスワード、Magic Link、SAML 2.0、SSO、Passkey（WebAuthn）、MFA
• 20+ の OAuth プロバイダ（Google, GitHub, Apple, LINE, X など）
• JWT を用いたセッション管理
• Row Level Security（RLS）と直結 — 認証ユーザーごとに行単位でアクセス制御

「ログインしたユーザーだけが自分の行を見られる」を、ミドルウェアではなく DB の制約として表現 できるのが Supabase Auth の最大の強みです。

3. Storage

• S3 互換のオブジェクトストレージ
• 画像変換 API（リサイズ、フォーマット変換）
• バケットに対しても RLS と同じ思想のポリシー を適用可能
• CDN 配信、署名 URL

4. Realtime

3 種類のチャネル：

協働ツール（Figma 風カーソル、Notion 風プレゼンス、共同編集など）の実装に強いです。

5. Edge Functions

• Deno ランタイム上で動くサーバーレス関数
• グローバルエッジに配置されてコールドスタートが速い（実測で50ms以下 との報告も）
• TypeScript/JavaScript で記述
• Stripe Webhook、画像処理、外部 API へのプロキシなどに最適

6. その他のプラットフォーム機能

• Branching: Git ブランチに連動して DB 環境ごと作成（Vercel Preview に近い体験）
• Read Replicas: 複数リージョンに読み取り専用 DB を配置
• Terraform Provider: IaC 化
• Log Drains: ログを Datadog/BetterStack 等に流す
• Database Vault: 機密情報の暗号化保存

クイックスタート - Next.js 16 で動かす

ここからは実際に Next.js 16 のプロジェクトに Supabase を組み込む例です。公式ドキュメントの手順に沿って進めます（Supabase Docs）。

1. テンプレートでセットアップ

npx create-next-app -e with-supabase

このテンプレートには Cookie ベース認証、TypeScript、Tailwind CSS、shadcn/ui コンポーネントが最初から組み込まれています。

2. 環境変数

.env.local に Supabase ダッシュボードの「Connect」から取得したキーを設定します。

NEXT_PUBLIC_SUPABASE_URL=https://xxxxxxxx.supabase.co
NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY=sb_publishable_xxxxxxxx

3. パッケージのインストール

非推奨になった auth-helpers-nextjs ではなく、@supabase/ssr を使います。

npm install @supabase/supabase-js @supabase/ssr

4. ブラウザ用クライアント

import { createBrowserClient } from "@supabase/ssr"
import type { Database } from "./database.types"
 
export const createClient = () =>
  createBrowserClient<Database>(
    process.env.NEXT_PUBLIC_SUPABASE_URL!,
    process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY!
  )

5. サーバー用クライアント（Server Components / Route Handlers）

import { createServerClient } from "@supabase/ssr"
import { cookies } from "next/headers"
 
export async function createClient() {
  const cookieStore = await cookies()
 
  return createServerClient(
    process.env.NEXT_PUBLIC_SUPABASE_URL!,
    process.env.NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY!,
    {
      cookies: {
        getAll() {
          return cookieStore.getAll()
        },
        setAll(cookiesToSet) {
          try {
            cookiesToSet.forEach(({ name, value, options }) =>
              cookieStore.set(name, value, options)
            )
          } catch {
            // Server Component から呼ばれた場合は無視（Middleware 側で更新される）
          }
        },
      },
    }
  )
}

6. データを取得する

todos テーブルから現在のユーザーのレコードのみを取得する例です。

import { createClient } from "@/utils/supabase/server"
 
export default async function TodoPage() {
  const supabase = await createClient()
  const { data: todos, error } = await supabase
    .from("todos")
    .select("id, title, completed")
    .order("created_at", { ascending: false })
 
  if (error) return <p>エラー: {error.message}</p>
 
  return (
    <ul>
      {todos?.map((t) => (
        <li key={t.id}>{t.completed ? "✓" : "□"} {t.title}</li>
      ))}
    </ul>
  )
}

auth のセッションは Cookie 経由で勝手に紐付き、後述する RLS ポリシーが効くため、「自分の todos しか取れない」が SQL レイヤーで保証 されます。

Row Level Security（RLS）- Supabaseの心臓部

Supabase を使う上で 絶対に外せない概念が RLS です。これは Postgres 標準機能で、「誰がどの行を読み書きできるか」 を SQL のポリシーとして定義します。

基本のポリシー

「ログインユーザーは自分の行しか SELECT できない」という、もっともよくあるパターン。

alter table todos enable row level security;
 
create policy todo_select_policy
  on todos for select
  using ( (select auth.uid()) = user_id );

auth.uid() は Supabase Auth がセットする現在のユーザー ID を返す関数です。

ロジックを関数化する

複雑な権限は SQL 関数として切り出せます。

create or replace function is_room_participant(room_id uuid)
returns boolean as $$
  select exists(
    select 1 from room_participants
    where room_id = is_room_participant.room_id
      and profile_id = auth.uid()
  );
$$ language sql security definer;
 
alter table messages enable row level security;
 
create policy "ルームメンバーだけメッセージを閲覧可能"
  on messages for select
  using (is_room_participant(room_id));
 
create policy "ルームメンバーだけメッセージを投稿可能"
  on messages for insert
  with check (
    is_room_participant(room_id) and profile_id = auth.uid()
  );

なぜ重要か：従来は Express や Rails のミドルウェアで権限をチェックしていましたが、その方式だと 生 SQL を直接叩かれた瞬間に破綻 します。Supabase は「クライアントから直接 PostgREST を叩く」ことを前提にしているため、DB 自体を最後の砦にする RLS が安全のすべてです。

Realtime のサンプル

Postgres の変更をリアルタイム購読する場合のクライアント側コードはこんな具合です。

const supabase = createClient()
 
supabase
  .channel("messages-changes")
  .on(
    "postgres_changes",
    { event: "INSERT", schema: "public", table: "messages" },
    (payload) => {
      console.log("新着メッセージ:", payload.new)
    }
  )
  .subscribe()

Realtime のメッセージにも RLS が適用できます。

create policy "ルームメンバーだけ private チャネルを購読可能"
on realtime.messages
for select to authenticated
using (
  topic like 'room:%'
  and exists (
    select 1 from room_members
    where user_id = auth.uid()
      and room_id = split_part(topic, ':', 2)::uuid
  )
);
 
create index idx_room_members_user_room
  on room_members(user_id, room_id);

2026年の最新アップデート

PostgREST 自動リトライ（2026年4月20日）

Supabase 公式クライアント全種で、GET / HEAD リクエストが一過性エラー（HTTP 520, 503, ネットワーク障害）に遭遇した場合、最大3回まで指数バックオフ（1s → 2s → 4s、上限30s）で自動リトライ されるようになりました。冪等な GET / HEAD のみ対象で、POST / PATCH / PUT / DELETE は自動リトライされません（Supabase Changelog）。

const supabase = createClient(url, key, {
  db: { retryEnabled: false }
})
 
const { data } = await supabase.from('table').select().retry(false)

Declarative Schema Management（pg-delta、2026年4月16日 Public Alpha）

これまで CLI のスキーマ差分は migra などサードパーティに依存していましたが、Supabase が TypeScript で書き直した独自スキーマ差分エンジン pg-delta を内包する 宣言的スキーマ管理ワークフロー が登場しました。

supabase db schema declarative sync

• supabase/database/ 配下の .sql ファイルが真のソース
• ファイル内の宣言順を意識する必要なし（pg-delta が依存関係を解決）
• スキーマを編集 → sync するだけで CLI が マイグレーション SQL を自動生成
• 破壊的変更（DROP）は警告
• --apply --name xxx で CI 化可能

これは Drizzle や Prisma の db push に近い体験で、「Postgres ネイティブな宣言的マイグレーション」 が Supabase 公式から提供される、という大きな進化です。

税務収集の追加（2026年5月1日〜）

請求書に消費税・VAT・GST が請求住所に基づいて自動加算されるようになります。日本拠点で利用している場合は、組織の請求住所と Tax ID（適格請求書発行事業者番号など）が正しく入力されているか確認しておきましょう。

Firebase との徹底比較

ここからが本題、Firebase との違い です。

全体比較表

料金比較

Supabase の Pro プランは 2021年3月から $25/月のまま で、ARR が $70M を超えても変わっていません（saaspricepulse.com）。コスト予測のしやすさ が経営者・開発者双方から評価されている要因の1つです。

アーキテクチャ思想の違い

こんな時は Supabase

• 複雑なクエリ（JOIN・集計・ウィンドウ関数）が必要な業務系アプリ
• SaaS / Web アプリが主戦場で、関係モデルが向いている
• コストの予測可能性 を重視
• ベンダーロックインを避けたい（将来的にセルフホスト含む乗り換えを残したい）
• 既に Postgres を運用しているチーム
• LLM/RAG のためにベクトル DB を 同じ DB に同居 させたい

こんな時は Firebase

• モバイルアプリ（特にオフライン同期が前提）
• プッシュ通知（FCM）が中核機能
• GA4 / Crashlytics / A/B Testing など Google マーケティング系と統合したい
• データモデルが単純な ドキュメント型 で十分
• アクセスが急増した時の自動スケールを最優先
• 「Postgres を運用したくない／したことがない」チーム

ハイブリッドという選択肢

「Web は Supabase、モバイルは Firebase（FCM のみ Firebase）」のように 使い分ける プロダクトも増えています。FCM をプッシュ通知用にだけ Firebase に残す のは特に現実解として人気です。

移行・併用するときの落とし穴

実際に Supabase を採用してハマりがちなポイントを補足しておきます。

まとめ

Supabase は、

• PostgreSQL をフルに使える BaaS で、SQL の知識がそのまま資産になる
• Auth / Storage / Realtime / Edge Functions / pgvector が標準同梱
• オープンソース・セルフホスト可能 でロックインが少ない
• 固定 $25/月 から始められる予測しやすい料金
• 2026年は pg-delta による宣言的スキーマ管理 や PostgREST 自動リトライ など、エンタープライズ運用に効く機能拡充が続く

一方の Firebase は、

• モバイル・オフライン同期・FCM に圧倒的な強み
• Google エコシステム との統合（Analytics, Crashlytics, AdMob）
• 自動スケールと、運用ノウハウの蓄積

という棲み分けが2026年時点でも明確です。「SQL で考える Web/SaaS は Supabase、ドキュメント型でモバイルは Firebase」 が現状の最適解と言えるでしょう。

迷ったら、まずは npx create-next-app -e with-supabase で30分ほど触ってみると、auth + RLS の体験のシンプルさに驚くはずです。

参考リンク

• 公式サイト：supabase.com
• 公式ドキュメント：supabase.com/docs
• 機能一覧：Features
• Next.js クイックスタート：Use Supabase Auth with Next.js
• 料金：Pricing
• Changelog：supabase.com/changelog
• pg-delta 発表：Declarative Schema Management with pg-delta
• GitHub：supabase/supabase
• Firebase 公式：firebase.google.com
• Supabase vs Firebase 2026 比較：tech-insider.org
• 実運用比較：Pockit Blog

関連記事

• Next.js App Router 完全ガイド
• LangChain.js とは - その活用例とコードサンプル
• モダンなテストフレームワーク Vitest と Playwright
• Self-hosted Git サーバー比較