製品比較

Busabase と Supabase：AI エージェントに使わせるなら

この記事が扱う問題を最も明確に述べているのは、Supabase 自身のガイダンスです。「Supabase MCP サーバーを本番データベースに接続することは強く推奨しません。」これは正しい助言です。同時に一つの問いが残ります——エージェントが本番に書き込むべきでないなら、その成果物はどこへ行くのでしょうか。

これは同じ仕事を奪い合う 2 製品の比較ではありません。Supabase はアプリケーションのバックエンドであり、非常に優れたものです。Busabase はエージェントが書き込むワークスペースであり記録システムです。有益な問いは「自分の課題はどの層にあるか」であり、多くのチームにとって正直な答えは「両方」です。

検証日：2026 年 9 月 17 日、Supabase の公開エージェント文書およびエンジニアリングブログに基づく。

エージェントを接続すべての比較

結論

Supabase を選ぶべき場合

：アプリケーションを作っているとき。認証、ストレージ、エッジ関数、OLTP、リアルタイム、ベクトル検索——それが本領であり、Busabase はそこを争いません。

Busabase を選ぶべき場合

：エージェントの成果物そのものが納品物であるとき。人や後続のエージェント実行が事実として読むレコード、ドキュメント、調査、ファイルで、自信を持って間違えられると高くつく場合。

両方使う場合

：これが一般的です。エージェントが作るアプリは Supabase 上で動き、エージェント自身の作業材料とその判断は人がレビューできる場所に置く。

Supabase はエージェントについて何を述べているか

Supabase は自らを「エージェント型ワークロードのために作られた完全な Postgres 開発者プラットフォーム」と位置づけ、「メモリ、ベクトル、認証、ファイルストレージ、API のために別々のサービスを寄せ集める」のをやめよう、と訴えます。エージェントがデータを問い合わせ、マイグレーションを実行し、関数をデプロイできる MCP サーバー、手続き的知識を与える Agent Skills、そして「すべてのデータベース呼び出しがテナント境界を尊重する」ための行レベルセキュリティ（RLS）を提供しています。

「アプリケーションのデータはどこに置くか」という問いに対して、一貫した、よく作り込まれた答えです。

Supabase が珍しく正直に書いている部分

同社のエンジニアリング記事「AI Agents Know About Supabase. They Don't Always Use It Right.」は、エージェントが自社プラットフォーム上で何を間違えるかを列挙しています。当社ではなく彼らのリストです。

エージェントは「公開スキーマで RLS ポリシーを飛ばす」；

security_invoker = true のないビューを作り、「これは RLS を静かにバイパスする」；

「UPDATE には SELECT ポリシーが必要で、ないと更新は静かに 0 行を返す」ことを見落とす；

「存在しない CLI コマンドを幻覚する」；

「ドキュメントを完全に無視し、数か月古いかもしれない訓練データに頼る」；

そして端的に「エージェントはその点で怠惰である」。

結論は証拠から素直に導かれます。エージェントはローカルかステージングに留め、本番には触れさせない。

これを引用するのは点を稼ぐためではありません。実在のバックエンドに対するエージェントの挙動について、両社が公開した中で最も正確な記述であり、そこから導かれる推奨も正しいものです。

これは層の問題であり、Supabase の欠陥ではない

先のリストの各項目に共通するものに注目してください。すべて正しさの失敗であり、それを捕まえることを期待されている仕組み——RLS——が管理するのは権限です。

RLS が答えるのはこの呼び出し元はこの行を書いてよいかです。それは非常に得意です。答えられないのはその値は正しいかです。完全に正しい権限を持つエージェントが、書く権限を完全に持つ列に、自信を持って誤った数値を書き込む——データベースのあらゆる検査を通過します。エンジンは何も間違っていません。レコードが偽であるだけです。

だから「エージェントを本番から遠ざけよ」は回避策ではなく妥当な助言です。エンジン層には他の答えが存在しないからです。「権限はあるが誤っている」書き込みを捕まえる検査はデータベースの中にはなく、書き込み経路の上にあります。

ではエージェントの成果物はどこへ

本番が使えない場合、チームは次の三つのいずれかに落ち着きます。最初の二つは見た目より悪い選択です。

エージェントがステージングに書き、人が手で移す。

正しいですが、エージェントで得た速度のほとんどを返上します。

エージェントがファイルやチャットログに書き、後で誰かが突き合わせる。

速いですが、その仕事はデータとして存在しなくなります。次の実行は読めず、何も帰属できません。

エージェントの書き込みを前提とした保管先に書く

—重要な書き込みが差分つきの提案として届き、検査され、それから正式なデータになる。

三つめが Busabase です。より安全なデータベースエンジンではなく——下は同じ Postgres です——書き込みの瞬間の契約が違います。

やりたいことで比べる

やりたいこと	Supabase	Busabase
アプリケーションにバックエンドを与える	まさに本領	担当外
認証・ストレージ・エッジ関数・リアルタイム	あり	なし
OLTP と高頻度のマシン書き込み	可能	不可 —— Supabase を使う
ベクトル検索 / RAG	可能	不可 —— Supabase かベクトルストア
誰が書けるかを制御する	RLS、成熟かつ細粒度	ノード単位・操作単位の権限
書かれた値を正式データにするか制御する	この層にはない	Change Request（フィールド単位の差分）
エージェントに本番へ安全に書かせる	明確に非推奨	そのために設計されている
出典・提案者・レビュアー・履歴をレコードに残す	アプリ側の責任	組み込み
エージェント出力をレビューする UI	自前で作る	製品そのもの

Supabase のほうが明確に優れている場面

ソフトウェアを出荷している。

成果物がユーザーのいるアプリなら、答えは Supabase で、この比較は僅差ではありません。

データベースのプリミティブが必要。

マイグレーション、コネクションプール、エッジ関数、リアルタイム購読、成熟した Postgres ツール。

書き込みがマシン規模。

テレメトリ、イベント、高頻度更新。その量ではレビュー経路は無意味で、当社もそう装いません。

エージェントがコーディングエージェント。

コードを書きマイグレーションを流すのが仕事なら、Supabase の MCP サーバーと Agent Skills はまさにそこを狙っており、その Skills の作りは実際に良いものです。

別のものが必要になる場面

エージェントの出力そのものが成果物：補強されたレコード、調査、ドキュメント、人が依拠する構造化知識。

誤った値が高くつき、しかも一目では誤りと分からない——RLS が構造的に捕まえられない類。

変更前に何が変わるかを人が見る必要があり、そのレビュー UI を自作したくない。

レコードに出典が必要：誰が提案し誰が承認したか。接続文字列を持っていたのは誰か、ではなく。

併用する

多くのチームが落ち着く分担は単純です。

エージェントが作るアプリは Supabase で動かし、エージェント自身が働く場所が Busabase。

エージェントが Busabase で調査しレコードを充実させ、人が重要な書き込みをレビューし、承認されたレコードは Busabase の API 経由でアプリが読み出す。アプリ自身の運用データは Supabase にある。どちらも相手の仕事をしておらず、どちらかを捨てなければもう一方が使えないということもありません。

正直な限界

Busabase はデータベースプラットフォームではありません。コネクションプーラーも、エッジ関数も、リアルタイム購読も、アプリのスキーマ用マイグレーションツールも、ベクトルインデックスもありません。それを求めて来たのなら、Supabase は単に優れた選択肢であるだけでなく、この二者の中で唯一の選択肢です。

Busabase は、相当量のエージェント作業にとって不要な一手間を加えるのも事実です。影響の小さい書き込みは速くあるべきで、実際に速く保っていますが、エージェントが書くもののうち一つも検査に値するほど重要でないなら、レビュー経路は不要なコストです。

よくある質問

Busabase は Supabase を置き換えますか

いいえ。層が違います。アプリにバックエンドが必要なら、引き続き必要です。

Busabase は承認キューつきの Postgres では

Postgres の上で動きますが、製品はワークスペースです。エージェントと人が共有する Base、ドキュメント、ファイル、Skill、小さなアプリがあり、レビューは重要な書き込みにのみ適用されます。

RLS とより良いプロンプトで解決できないのですか

RLS は値の真偽を評価できず、プロンプトはエージェントを信頼できるものにしません。Supabase 自身の記事が、手元にあった指示を無視するエージェントの目録になっています。

同じ実行で Busabase と Supabase の両方に書けますか

できますし、それが普通の形です。運用データはアプリのバックエンドへ、レビューすべき重要な出力はワークスペースへ。

Butterbase など他のエージェント向けバックエンドは

同じ層の話が当てはまります。「アプリのデータをどこに置くか」に答えるものであり、「エージェントの成果物がどう信頼に足るものになるか」ではありません。当社は Supabase について一次調査を行ったため、本ページは Supabase に絞っており、同程度に精査していない製品について断定はしません。

次のステップ

書き込み経路の主張を検証したいなら、最短はすでに使っているエージェントを接続し、重要な書き込みが「検査できる形」で届くのを見ることです。

AI エージェントの記録システムとは何か · Busabase と Notion · エージェントを接続する

出典：Supabase for Agents、「AI Agents Know About Supabase. They Don't Always Use It Right.」、Supabase AI Tools ドキュメント。引用は上記検証日時点で公開されている Supabase 自身の記述です。