BaaSプラットフォームの徹底比較：Firebase、Supabase、Appwriteのアーキテクチャ評価

はじめに：Backend-as-a-Serviceの進化

Backend-as-a-Service（BaaS）プラットフォームは、単なるモバイル向けバックエンド支援から、現代のフルスタックWebアプリケーションの中核インフラへと進化しました。認証、データベース、ファイルストレージ、サーバーレス関数といった定型基盤を抽象化することで、エンジニアはユーザー価値の創造に集中できます。

しかし、BaaSエンジンの選択はアーキテクチャ上の極めて重大な決定です。後からの移行は、クライアントSDK、セキュリティルール、データスキーマの大規模な書き換えを伴います。現在、市場を牽引する3大プラットフォームはそれぞれ異なる設計思想を持っています：

Google Firebase: フルマネージドで実績のあるクラウドBaaS。GCP独自エコシステムと深く統合。
Supabase: 「オープンソースのFirebase代替」。PostgreSQLを中核とし、リレーショナル規格とSQLの表現力を活用。
Appwrite: コンテナファーストで完全なセルフホスティングが可能なオープンソースBaaS。データ主権と自社インフラ運用を重視。

本ガイドでは、データモデル、アクセス制御、リアルタイム通信、エッジ関数、ロックインリスクの観点から客観的に比較します。

1. アーキテクチャの概要と設計哲学

評価軸	Google Firebase	Supabase	Appwrite
コアエンジン	Cloud Firestore (NoSQL)	PostgreSQL (RDBMS)	MariaDB / Redis / Custom
データ構造	コレクション & ドキュメント	テーブル, 行, リレーション	データベース, コレクション, ドキュメント
リレーショナル結合	非対応（非正規化が前提）	完全なSQL JOIN対応	内部リレーション機能
インデックス	自動複合インデックス	B-Tree, GIN, GiSTなど柔軟	管理画面からの手動インデックス設定
アクセス制御	宣言的セキュリティルール	PostgreSQL 行レベルセキュリティ (RLS)	ドキュメント単位のパーミッション配列

2. データモデルとクエリ比較

Firestore (NoSQL ドキュメント)

Firestoreは高速な読み取りに最適化されていますが、複雑な集計や多対多のクエリには制限があります：

import { collection, query, where, getDocs } from 'firebase/firestore';

const q = query(
  collection(db, 'invoices'),
  where('tenantId', '==', 'tenant_123'),
  where('status', '==', 'unpaid')
);
const snapshot = await getDocs(q);

Supabase (リレーショナル PostgreSQL)

PostgRESTを活用し、1回のリクエストで結合テーブルのデータも同時に取得できます：

import { supabase } from './supabaseClient';

const { data, error } = await supabase
  .from('invoices')
  .select(`
    id,
    amount_cents,
    customers (
      name,
      email
    )
  `)
  .eq('tenant_id', 'tenant_123');

3. セキュリティと認可モデル

Firebase セキュリティルール

独自のDSL構文で定義します：

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /invoices/{invoiceId} {
      allow read, write: if request.auth != null 
        && request.auth.token.tenant_id == resource.data.tenantId;
    }
  }
}

Supabase 行レベルセキュリティ (RLS)

PostgreSQLネイティブのRLSポリシーを利用するため、外部ツールや直接接続時にも同一のセキュリティが保証されます：

ALTER TABLE invoices ENABLE ROW LEVEL SECURITY;

CREATE POLICY tenant_isolation_policy ON invoices
  FOR ALL
  USING (
    tenant_id = (auth.jwt() -> 'app_metadata' ->> 'tenant_id')::uuid
  );

4. リアルタイム通信の仕組み

Firebase: Firestoreのリアルタイムリスナー。ドキュメント変更時の差分計算が高度に最適化されており、モバイル端末でも軽量に動作します。
Supabase Realtime: PostgreSQLのWrite-Ahead Log (WAL) を論理デコード（pgoutput）し、Phoenix Channels（Elixir WebSockets）経由でクライアントへブロードキャストします。
Appwrite Realtime: 内部のRedis Pub/Subを活用し、WebSocketワーカーを通じて購読クライアントへイベントを即座に通知します。

5. セルフホスティングとベンダーロックイン

Firebase: 完全なプロプライエタリクラウドであり、セルフホストは不可能です。移行時はNoSQLドキュメントのエクスポートとスキーマ再構築が必要になります。
Supabase: Docker ComposeやKubernetesにより完全なセルフホストが可能。標準のpg_dumpでエクスポートでき、そのままAWS RDS等の標準Postgres環境へ移行できます。
Appwrite: 1行のDockerコマンドで数分でセルフホスト環境が構築可能。プライベートクラウドやオンプレミス運用に最適です。

結論と選択基準

Supabaseを選ぶべき場合: SQLリレーション、トランザクション、外部キー結合、pgvector等のPostgres拡張機能を活用したい一般的なSaaSおよびWebアプリケーション。
Firebaseを選ぶべき場合: Google AnalyticsやCrashlyticsと統合されたモバイルアプリや、サーバー管理を一切行いたくないプロトタイプ開発。
Appwriteを選ぶべき場合: データの完全な自社管理（オンプレミス・データ主権）が必須であり、Dockerコンテナとして独立運用したいプロジェクト。