Supabase は、認証や RLS（Row Level Security）を含めて、
フロントエンドから安全に PostgreSQL を扱える優れた BaaS です。
しかし、サーバーサイドからデータを取得する文脈では、
Supabase SDK を使い続けることが最適とは限りません。
本記事では、
「Supabase からサーバーサイドでデータを取得する際に、
Supabase SDK を使うべきでない3つの理由」
- パフォーマンスが悪い
- セキュリティリスクが高い
- 自由度が低い
について解説していきます。またその代替手段であるDirect Connectionを使えばどう解決するのか解説していきます。
Supabase のアーキテクチャを理解する
Supabase は、PostgreSQL の前段に
複数の HTTP ベースのサービス層を配置したアーキテクチャを採用しています。
Supabase SDK は PostgreSQL に直接接続するのではなく、
- PostgREST（/rest）
- Realtime
といったエンドポイントに HTTP リクエストを送ることで、
最終的にデータベースへアクセスします。
この構造は、
フロントエンドから安全に DB を扱うという Supabase の主用途では非常に優れています。
一方で、サーバーサイドから使う場合は欠点になります。その結果 パフォーマンス・セキュリティ・自由度 の問題につながります。
Direct Connection とは
Direct Connection とは、
Supabase が提供する HTTP API や SDK を介さず、
PostgreSQL に 直接接続してデータを操作する方法です。
具体的には、
- PostgreSQL の接続文字列を使う
- ORM や Query Builder（例: Kysely, Prisma など）から接続する
といった形になります。
パフォーマンス上の欠点
Supabase SDK をサーバーサイドで使う場合、
アーキテクチャの特性上、どうしても余計なレイヤーを経由することになります。
Supabase SDK は PostgreSQL に直接接続するのではなく、
- HTTP リクエスト
- 認証・認可（JWT / RLS）
- API レイヤー（PostgREST など）
を通過したうえで、ようやくデータベースに到達します。
フロントエンドから使う場合、この構造は必須です。
しかしサーバーサイドでは、
- 実行環境はすでに信頼されている
- 認証はアプリケーション側で完結している
にもかかわらず、不要な認証フローや抽象レイヤーを毎回通ることになります。
その結果、クエリごとの レイテンシーが積み重なります。
サーバーレスデータベースのレイテンシー比較
以下の記事では、サーバーレスデータベースや
HTTP 経由のデータアクセスにおけるレイテンシーが比較されています。
この比較からも分かる通り、
HTTP ベースで DB にアクセスする方式はレイテンシーが高くなりやすいことが示されています。
Direct Connectionを使えばこの問題は必然的に解決できます。より低レイテンシーで予測可能なパフォーマンスを得やすくなります。
セキュリティ上の欠点
Supabase SDK は HTTP API を通じてデータにアクセスするため、
- API エンドポイント自体に firewall を設定できない
- IP 制限やネットワークレベルでの遮断ができない
という制約があります。
サーバーサイドでは多くの場合、
RLS を回避するために Service Role Key を使用します。
しかしこのキーが一度でも流出すると、
認証・認可を完全にバイパスした状態で、
すべてのデータにアクセス可能
になってしまいます。
一方で、PostgreSQL への direct connection を採用した場合は状況が異なります。
- firewall による IP 制限が可能
- VPC / ネットワークレベルでの防御ができる
- 仮に DB パスワードが流出しても、
接続元を制限することで被害を抑えられる可能性がある
つまり、
- Supabase SDK：鍵（Service Role Key）に依存したセキュリティ
- Direct connection：鍵＋ネットワーク境界による多層防御
という違いがあります。
サーバーサイドでは後者の方が、
より堅牢で現実的なセキュリティ設計を取りやすくなります。
自由度が低い
Supabase SDK はシンプルな CRUD 操作には向いていますが、
サーバーサイドで必要になる 複雑なデータ操作 になると、
自由度の低さが目立ってきます。
まず、複数テーブルをまたぐ JOIN クエリ が書きづらく、
クエリが複雑になるほど表現力に限界を感じやすくなります。
また、Supabase SDK では
トランザクションを扱うことができません。
回避策として rpc（PostgreSQL の関数）を使う方法はありますが、
- トランザクションが必要な処理ごとに RPC を定義する必要がある
- SQL ロジックが DB 側に散らばる
- アプリケーションコードとの対応関係が見えにくくなる
といった問題が生じ、管理コストが高くなりがちです。
Direct connectionの場合は
- JOIN
- トランザクション
- 複雑なクエリ構築
をすべてアプリケーション側で自然に扱うことができ、
サーバーサイドに求められる柔軟な設計が可能になります。
それでも Supabase をサーバーサイドから使う価値はあるのか？
ここまで、Supabase SDK をサーバーサイドで使う際の欠点を述べてきました。
では、Supabase 自体に価値がないのかというと、決してそうではありません。
Supabase は、Direct Connection 前提であれば
サーバーサイドでも十分に魅力的な選択肢になります。
使いやすいGUI
SupabaseはGUIツールとして優れています。データの可視化だけではなく、接続ログやスロークエリの検出まで、様々な機能を備えています。Direct Connectionでもこの恩恵を受けることができます。
魅力的な価格
Supabase の料金体系は、
他のサーバーレスDBと比べても比較的安価です。
低レイテンシー（Direct Connection 前提）
先ほど紹介したレイテンシー比較の画像を見ると、
SupabaseのTCP 接続によるデータベースアクセスは非常に高速であることが分かります。
Supabase で Direct Connection を使えば、
この 低レイテンシーな TCP 接続の恩恵をそのまま受けることができます。
まとめ
Supabase は、
- フロントエンドでは SDK が強力
- サーバーサイドでは Direct Connection が本領
という性質を持っています。
Supabase SDK をサーバーサイドで無理に使うのではなく、
Supabase を「PostgreSQL 基盤」として使うことで、
価格とパフォーマンスの両立が可能になります。
