Supabase vs Notion：どちらに作るべきか

「Supabase vs Notion」と検索する人がいるのは、両方の製品が最終的に同じものを抱えるからです。チームのデータが、テーブルの形で入っている。顧客リストは Notion に置かれ、やがて API が必要になる。ユーザーアカウントは Supabase に作られ、やがて「フォローアップのメモはどこに置くのか」と聞かれる。比較したくなるのは自然ですが、この比較は出発点から少しずれています。両者はそもそも同じ種類の製品ではないからです。

結論を先に。 製品を作り、アプリケーションが一日中読み書きするデータなら Supabase。チームの知識——ドキュメント、意思決定、プロジェクト管理など、人が毎朝開くものなら Notion。そして、書き手がますます AI エージェントになっているなら、この二つの答えはどちらも変わります。それが本記事の最後のセクションであり、前半をすでに知っている人にも読む価値のある部分です。

それぞれの正体

Supabase は Postgres プラットフォームです。 ダッシュボードの下には本物の専用 PostgreSQL データベースがあり——完全な SQL、制約、トランザクション、結合、埋め込みが必要なら pgvector——その周りにアプリのバックエンドが通常必要とするもの、認証、ファイルストレージ、エッジ関数、リアルタイム購読が揃っています。開発者は SQL、REST、GraphQL API、各言語のクライアントライブラリで駆動します。製品をその上に作るためのデータベースです。

Notion は、テーブルを覚えたドキュメント・ワークスペースです。 Notion ではすべてがページであり、「データベース」とはプロパティ——ステータス、担当者、期限——をまとったページの集まりで、ビュー、リレーション、ロールアップ、関数が上に乗っています。人が読み、議論し、並べ替える仕事には抜群に強い。しかし SQL はなく、トランザクションも結合もありません。外部からのアクセスは連携と同期のために設計された API で、レート制限もそれ相応であり、本番のアプリのクエリを捌くためのものではありません。

この一点の違い——データベースが使いやすいプラットフォームを周りに育てたのか、ドキュメントツールがデータベースの形をしたテーブルを育てたのか——が、以下のほぼすべての行を決めます。

正面比較

Supabase が勝つところ

ソフトウェアが依存するデータ全般です。「このユーザーの未払い注文を、在庫と結合して、トランザクションの中で答える」——これは Postgres への問いであり、Notion には聞き取れません。データの規律でも Supabase が勝ちます。制約と外部キーは悪いデータを入口で弾き、手入力のプロパティの中に静かに溜め込ませません。行レベルセキュリティ（RLS）を使えば、誰が何を見られるかをデータベース自身に強制させられます。AI 機能では pgvector が、埋め込みをそれが表す行の隣に置き、第二のシステムを不要にします。

正直なコストも書きます。Supabase は開発者ツールです。運用担当者はテーブルエディタで内容を確認したがりませんし、会議のメモを書く場所でもありません。料金は月額 $25 から始まりますが、コンピュートと帯域の使用量に応じて従量で伸びます。

Notion が勝つところ

チームが読むもの全般です。プロジェクト管理、意思決定の記録、オンボーディング文書、創業者が実際に自分の手で更新する CRM の形をしたリスト——Notion が勝つのは、人がすでにそこにいるからであり、誰も開かないデータベースは腐るだけです。そのテーブルは初期の仕事の「整っていなさ」に寛容で、プロパティを足し、ビューを変え、ドキュメントをレコードに貼れます。コメントとメンションがあるので、単なる保管場所ではなく協働の場です。

代償も本物です。寛容さは裏表一体で、制約がなければ同じステータスが三通りの綴りで溜まります。クエリはフィルタとロールアップで止まり、結合が必要になった瞬間、誰かがスプレッドシートに書き出します。そしてメンバー単位の課金は、蓄えたデータ量ではなく人数でコストが伸びることを意味します。

両方使う——そして守るべき唯一のルール

多くのチームは結局両方を使います。それで問題ありません。Notion は物語（計画、メモ、意思決定）に、Supabase はアプリケーション（アカウント、注文、製品データ）に。壊れるのはただ一つの形だけです。同じデータセットが両方に静かに置かれ、両方で編集され、どちらが正か誰にも言えなくなること。防ぐルールは一つだけ。データセットごとに正の置き場所を一つだけ決め、もう一方はリンクすること。手でミラーしてはいけません。 人が保守するものは Notion に、ソフトウェアが依存するものは Supabase に。争いはそこで終わります。

答えを変える問い：書き手は誰か

ここまでの議論はすべて「人が書き、ソフトウェアが読む」ことを前提にしています。その前提は期限切れになりつつあります。両ベンダーとも公式 MCP サーバーを出しており、エージェントは今日どちらの製品にも接続できます。詳細が重要です。

• Supabase の MCP サーバーは、単一プロジェクトへの限定ができ、読み取り専用モード（すべてのクエリが読み取り専用の Postgres ユーザーで実行される）に切り替えられます。Supabase 自身のドキュメントはこれを開発とテストの用途に位置づけ、本番データへの注意を促し、エージェントのクライアント側でツール呼び出しの手動承認を有効に保つことを推奨しています。
• Notion の MCP サーバーは OAuth でサインインし、ちょうどあなた本人の権限で動きます。ワークスペース全体のページとデータベースを検索、読み取り、作成、更新できます。

両設計の共通点に注目してください。統制しているのは接続であって、書き込みではありません。統制が決めるのは、エージェントが何に触れるか。しかし書き込みはいったん起きれば、直接的かつ最終的に着地します。承認があるとしても、それはチャットのクライアントがその場で「このツール呼び出しを実行しますか」と聞くものであり、データそのものの上に置かれたレビュー可能な提案——diff があり、同僚が明日見て、議論して、マージも却下もできるもの——ではありません。「エージェントが提案したデータ」と「チームが受け入れたデータ」の区別は、どちらの製品にもありません。

エージェントが毎日書くようになったら、この区別こそが勝負のすべてです。エージェントが更新する CRM、エージェントが保守する知識ベース、エージェントが夜のうちに整理するレコード。必要なのはエージェントを遅くすることではなく、重みのある書き込みは提案として届き、軽いものは直接着地する仕組みです。Busabase はまさにその層のために作りました。エージェントのための Notion × Supabase ハイブリッドです。レコード、ドキュメント、Skills が一つのワークスペースにあり、エージェントの書き込みはすべて diff と履歴を持つチェンジリクエストになります。書き込み権限のキーならそのままマージされ、「提案のみ」のキーなら人のレビューを待ちます。接続は MCP、Agent Skill、API、CLI のいずれでも可能です。料金は席単位の定額（Plus は席あたり月額 $10、Pro は $20、年払い）、従量課金はなく、エンジンはオープンソースなので、レコード層を自分でホストすることもできます。項目ごとの比較は Busabase と Supabase の比較に、より長い議論は「Supabase と Busabase：記憶とルールの層」にあります。

シナリオ別の裁定

よくある質問

Notion はアプリのデータベースになれますか。 プロトタイプや社内ツールでは、そうしているチームがあります。天井は早く来ます。SQL がなく、結合もトランザクションもなく、API は本番トラフィックではなく同期のために作られています。本物のソフトウェアがそのデータに依存し始めたら、本物のデータベースへ移し、Notion からはリンクさせてください。

Supabase はチームドキュメントで Notion の代わりになれますか。 テキストを Postgres に保存することはできます。保存できないのは習慣です。ドキュメント編集の体験も、コメントの文化も、チームが毎朝自発的に開くページもありません。誰も読まない Wiki は、Wiki がないより悪いものです。

どちらが安いですか。 小規模なら両方ともほぼ無料で、この問いは気を散らすだけです。形は違います——Notion は人数で、Supabase はプロジェクトと使用量で伸びます——が、高くつくのは購読料ではありません。間違った形を選び、一年分のデータをそこに溜めてから、移行の代金を払うことです。