Supabase は、PostgreSQL を中核に据えた BaaS（Backend as a Service）だ。データベース・認証・ストレージ・サーバーレス関数・リアルタイム通信を一つのプラットフォームでまとめて提供し、バックエンドを自前で組む手間を大きく削る。

Firebase との実質的な違い

「Firebase の代替」と語られることが多いが、決定的な違いは中身が本物の PostgreSQL である点だ。SQL がそのまま使え、JOIN もトランザクションも外部キー制約も普通に書ける。リレーショナルなデータモデルを持つアプリでは、ドキュメント DB より素直に設計できる。将来 Supabase から離れたくなっても、PostgreSQL のダンプを持ち出せるためロックインが浅い。

何が同梱されるか

  • 認証: Email / OAuth / Magic Link に対応し、ログイン機能を一から作らずに済む
  • ストレージ: 画像やファイルのアップロード先
  • Edge Functions: Deno ベースのサーバーレス関数
  • Realtime: DB の変更を WebSocket で購読できる

RLS という最大の落とし穴

実装で最も事故が起きやすいのが Row Level Security（RLS）だ。Supabase はクライアントから直接 DB を叩ける構成のため、テーブルごとに RLS ポリシーを正しく書かないと、誰でも全行を読み書きできる状態になる。「無効のまま公開してデータが筒抜けだった」というのは典型的なインシデントで、テーブルを作ったら必ずポリシーを設計する、という習慣が前提になる。

スケール時の注意

無料枠は実用的に充実しており、個人開発やプロトタイプのバックエンドとして始めやすい。一方、無料枠のプロジェクトは一定期間アクセスがないと一時停止されるため、滅多に触らない検証環境では「動かない」と戸惑いやすい。有料はプロジェクト単位の月額制だが、規模が伸びると DB の同時接続数がボトルネックになりやすく、サーバーレス関数を多用する構成では接続プーラ（Supavisor 等）の利用が前提になる。当然ながら PostgreSQL 専用なので、他の DB エンジンが要件なら選択肢から外れる。

RLS を「後で書く」と決して間に合わない理由

Row Level Security は機能の一つではなく、Supabase の設計そのものに組み込まれた前提だ。クライアントから DB を直接叩ける構成である以上、ポリシーを書いていないテーブルは「誰でも触れるテーブル」になる。開発中は anon キーで自由に読み書きできるほうが速いため、RLS を無効のまま進めたくなるが、この状態のまま公開すると全データが露出する。

🔴
テーブルを作った直後にポリシーを書く、を習慣にしてください

「公開前にまとめて RLS を設定する」という進め方は、テーブル数が増えた段階で必ず漏れます。漏れた1テーブルが全件露出につながるため、テーブル作成とポリシー作成をセットの作業として扱うのが唯一現実的な運用です。

接続数がスケールの壁になる

PostgreSQL は接続ごとにプロセスを持つため、同時接続数に上限がある。サーバーレス関数から都度接続する構成だと、トラフィックが伸びた瞬間に接続数を使い切って接続エラーが多発する。これは Supabase 固有の問題ではなく PostgreSQL の性質だが、サーバーレスと組み合わせたときに顕在化しやすい。接続プーラ（Supavisor）を経由する構成を最初から前提にしておくと、後から慌てずに済む。

移行しやすさをどう評価するか

Supabase を選ぶ実務的な理由のひとつが「抜けやすさ」だ。中身が標準の PostgreSQL なので、pg_dump でデータを吸い出して別の環境に載せ替えられる。認証やストレージは Supabase 固有の作りなので完全に無傷とはいかないが、少なくともデータ本体が人質にならない。BaaS を選ぶときに気になる「将来動けなくなるのでは」という懸念に対して、これは実質的な答えになる。