MCPデータベースサーバー比較：クラウドリレー vs ローカルMCP

1年前、「AIにデータベースを見させる」はパーティーの芸でした。MCPサーバーを配線し、Claudeにテーブルを一覧表示するよう頼み、それがやるのを眺め、それからタブを閉じて実際のワークフローに戻りました。それは洒落ていました。そして、重要なものに任せるには信頼できないほど粗削りでもありました。

それは変わりました。MCP対応は、人々が実際に使うアシスタント——Claude Desktop、Cursor、Windsurf、Codex——の間で標準になり、サーバーは良くなりました。スキーマ検出は機能し、クエリ生成は機能し、そのループは、私が意識せずに一日に何度も手を伸ばすほど信頼できるようになりました。

つまり、興味深い問いは移りました。もはやAIをデータベースに接続するかどうかではありません。接続がどこに存在するかです。その一つの決定が、誰があなたの認証情報を保持するか、あなたのデータがモデルに至る途中で何に触れるか、そしてチームメイトが同じ設定を使えるかどうかを決めます。

一般的に使われる3つのアーキテクチャがあり、多くの「データベース向けMCP」のまとめ記事で、交換可能であるかのように一括りにされます。そうではありません。私は3つすべてをセットアップし、そのうちの一つを製品に組み込みました。ですから意見があります。しかしこれはクラウドの選択肢を叩く記事ではありません——それらは現実の問題を解決しており、そう述べます。要点は、最初に読んだチュートリアルがやれと言ったものにデフォルトするのではなく、意図的に選べるようにする、澄んだ地図です。

MCPデータベースサーバーとは実際何か

マーケティングを取り払えば、データベースMCPサーバーは小さく、ほとんど退屈なものです。それはデータベース接続を保持し、それを呼び出し可能なツールの集合としてAIアシスタントに公開するプロセスです。

MCP——Model Context Protocol——はまさにこのためのオープンプロトコルです。JSON-RPCベースで、これはクライアントとサーバーが構造化されたリクエストとレスポンスのメッセージを交換するという気取った言い方です。クライアントはあなたがチャットしているAIアシスタントです。サーバーは実際の作業を行う別のプロセスです。クライアントは会話に基づいてツールをいつ呼ぶかを決めます。あなたは手動で何も呼び出しません。「先週の注文を見せて」と言うと、アシスタントは何らかのSQLでクエリツールを呼ぶべきだと判断します。

データベースサーバーは通常、この線に沿った少数のツールを公開します。

list tables——データベース内のテーブルを列挙する
describe schema——与えられたテーブルの列、型、制約を返す
run query——SQL文を実行して行を返す
execute——データやスキーマを変更する文を実行する（しばしばフラグの背後に制限される）

正確な名前はサーバーごとに異なりますが、形は一貫しています。AIは接続時にツール定義を読み、run queryツールが存在するのを見て、質問が実データを要するときにそれに手を伸ばせると知ります。

人々が見落とすのは、クライアントとサーバーの分割と、サーバーがどこで動いていようとあなたのデータベースに何らかの方法で到達しなければならないという事実です。2つのトランスポートが一般的です。ローカルstdioは、サーバーがAIクライアントの子プロセスで、あなたのマシン上で動き、標準入出力で話すことを意味します——ネットワークはまったく関与しません。HTTPまたはSSEは、サーバーがネットワーク経由で到達可能であることを意味し、クライアントと同じマシンで動いていないときに必要になるものです。

このハンズオンの版——実際の設定ファイルとステップバイステップのセットアップ——が欲しいなら、データベース用ローカルMCPサーバーのセットアップで完全なウォークスルーを書きました。この記事は比較であり、あちらはチュートリアルです。

3つのアーキテクチャ

人々がMCPデータベースサーバーを本番に投入する方法は3つあります。チャットウィンドウからは同じに見えます。内側は大きく異なります。

クラウドリレー

クラウドリレーはホスト型のMCPエンドポイントです。自分でサーバーを動かす代わりに、サービスにサインアップし、データベース接続の詳細——接続文字列、あるいはあなたのデータベースへのOAuth付与——を渡すと、MCPクライアントの設定に貼り付けるURLをくれます。AIクライアントはベンダーのクラウドにツール呼び出しを送り、ベンダーのクラウドがあなたのデータベースに対してクエリを実行し、結果は同じ道を戻ってきます。

魅力は明白で、それについて公平でありたいと思います。セットアップは本当にゼロです。インストールするプロセスも、管理するランタイムも、URL以外の設定ファイルもありません。ソフトウェアをインストールできないロックダウンされた社用ノートPCを含め、どのマシンからも動きます。そして共有可能です——チーム全体が同じエンドポイントを指せ、これはローカルの設定が苦戦することです。あなたの組織に「AIのためのデータベースアクセス」をマネージドな社内サービスとして提供したい中央のプラットフォームチームがあるなら、リレーモデルは自然な適合であり、これらのサービスのいくつかは、素のローカルサーバーにはないクエリログ、レート制限、監査証跡を加えます。

代償は声に出して言えば同じくらい明白です。あなたの接続認証情報は他人のサーバー上にあり、あなたが実行するすべてのクエリ——SQLとそれが返す行——が彼らのインフラを通過します。それは2つの別々の露出です。認証情報の方はより気になります。データベース認証情報は、あなたが実行した一つのクエリだけでなく、データベース全体への鍵だからです。データの露出は人々が最初に挙げがちなもので、それは現実です。結果セットはあなたへ戻る途中とモデルへ向かう途中でリレーを通ります。

これらはどれもリレーを悪いと呼ぶ理由ではありません。何を買っているのかを正確にする理由です。リレーは信頼の決定です——そうでなければ二者である経路に第三者を加える価値が、ゼロセットアップの便利さにあると決めているのです。データがすでに広くアクセス可能な読み取り専用の分析データベースなら、その取引は問題ないかもしれません。顧客レコードを持つ本番データベースなら、通常はそうではありません。

セルフホストのリモート

中間の選択肢は、MCPサーバーを自分で動かすが、ノートPC上ではないことです。VPS、コンテナ、あるいは社内ホストに立ち上げ、AIクライアントがHTTP経由でそれに接続します。これは「第三者のいないリレーの到達範囲が欲しい」という選択肢です。

あなたがホストを制御します。認証情報を制御します——それらはベンダーのものではなく、あなたが所有するインフラ上にあります。VPNの背後に置き、プライベートサブネットに置き、既存の認証に配線し、好きなようにログを取れます。

トレードオフは、常時稼働のサービスを引き受けたことです。そのサーバーは今や、データベース接続とネットワークリスナーを持つ長時間稼働のプロセスであり、認証表面、パッチ適用のペース、可用性の話を持ちます。設計上ネットワークから到達可能です——それが要点です——ので、問いは誰がそれに、何を持って到達できるかになります。堅牢な認証を前に置かずにインターネットに露出するなら、あなたはデータベースプロキシを作ってドアを開けっ放しにしたことになります。

セルフホストは一部のチームにとって正しい答えです——特に社内サービスを上手く運用する運用成熟度を持つチームには。ローカルのPostgresをAIに見せたいだけのソロ開発者には悪い答えです。メンテナンスのオーバーヘッドが何ももたらさないからです。

ローカルMCP

ローカルMCPは3つの中で最も推論が単純です。サーバーはあなたのノートPC上のプロセスです。クライアントとstdio経由、あるいはlocalhostに束縛されたHTTP経由で話します。認証情報は決してマシンから出ません。それらを保持するマシンがサーバーの動くマシンであり、クライアントもそのマシン上にあるからです。

流れは一行で言えるほど短いです。AIクライアント → ローカルサーバープロセス → あなたのデータベース、すべてあなたが制御するハードウェア上。その経路の何も、越える必要のないネットワーク境界を越えません。データベース自体がローカル——SQLiteファイル、あるいはDockerで動くPostgresインスタンス——なら、ループ全体がwifiを切って動けます。これは他のどのアーキテクチャも持たない特性です。

トレードオフは、マシンごとであることです。あなたの設定はあなたのノートPC上にあります。チームメイトのノートPCはそれ自身のものを持ちます。共有エンドポイントも、更新する中央の場所も、ある人の丁寧なセットアップが他の誰かの利益になる方法もありません。データベース認証情報をローテーションするなら、あなたのマシンの一箇所と、他の全員のマシンで別々にローテーションします。ソロ開発者や小規模チームには、それは丸め誤差です。50人の組織には、それがあなたをリモートの選択肢のどれかへ押しやるものです。

名付けておく価値のあるしわもあります。ローカルMCPはマシンと同じくらいしか安全ではありません。ノートPCが侵害されれば、それが保持するデータベース接続も侵害されます。しかしそれはマシン上のどの認証情報にも当てはまるので、ローカルMCPに特に不利な点ではありません——それは標準的なエンドポイントセキュリティの姿勢であり、「第三者が私の本番データベースへの鍵を保持する」より小さく、なじみ深い問題です。

比較

並べての比較は以下のとおりです。最も重要な列は最後のものですが、中央の列に本当のトレードオフがあります。

アーキテクチャ	認証情報の場所	セットアップの手間	チーム共有	データはマシンから出るか？
クラウドリレー	ベンダーのサーバー	最小——サインアップ、接続文字列を貼り付け、URLをコピー	組み込み——全員に一つのエンドポイント	はい——クエリと結果がベンダーを通過
セルフホストのリモート	あなたのホスト（VPS／コンテナ／社内）	中程度——サービスをデプロイ、保護、保守	はい、共有すれば——加えてアクセス管理	はい——クライアントマシンを離れてあなたのサーバーへ
ローカルMCP	あなたのマシンのみ	低——マシンごとにインストールし設定	いいえ——設計上マシンごと	いいえ——サーバーはあなたのマシンで動く

この表からいくつかのことが導かれます。

第一に、「データはマシンから出るか」と「モデルに届くか」は2つの異なる問いであり、混同しがちです。ローカルMCPでは、認証情報は決して出ませんが、クエリの結果は依然としてAIプロバイダへ行きます。モデルがあなたに答えるためにそれらを見る必要があるからです。これはこのすべての仕組みの根本です——AIがあなたのデータを見ずに、あなたのデータについて推論することはできません。ローカルMCPが取り除くのはリレーです。あなたのマシンとモデルの間に座る余分な当事者です。モデル自体は取り除きませんし、どのアーキテクチャもそうしません。

第二に、セットアップの手間の列はそれ自体では誤解を招きます。最初の1時間を測っており、100時間目を測っていないからです。クラウドリレーは最初の1時間を決定的に勝ちます。セルフホストのリモートは最初の1時間を失い、パッチを当てる、ローテーションする、デバッグするたびに失い続けます。ローカルMCPは最初の1時間が楽で、楽なままですが、「チーム共有」の列でその代償を払います。

第三に、チーム共有はローカルモデルが本当に弱い唯一の場所であり、そうでないふりはしません。あなたの組織がAIのための共有された、マネージドな、監査可能なデータベースアクセス層を必要とするなら、リモートアーキテクチャが正しい選択です。以上です。ローカルMCPは個人のツールであり、そのように評価するのが最善です。

データベースMCPサーバーで見るべきもの

どのアーキテクチャを選ぼうと、サーバー自身の機能セットは極めて重要です。AIに渡されたデータベース接続は強力なものであり、注意深いサーバーと不注意なサーバーの違いは、実データに使えるツールと負債の違いです。私が実際に確認することを挙げます。

読み取り専用モード。 これは最低条件です。良いサーバーは、SELECTとスキーマ検査を許可しつつ、書き込むもの——INSERTなし、UPDATEなし、DELETEなし、DDLなし——を拒否するよう設定できます。失う余裕のないデータベースには、これは探し回らなければならないオプションではなく、デフォルトであるべきです。

ソースごとのスコープ。 複数のデータベースが接続されているなら、サーバーはどれがAIに公開されるかを選ばせてくれるべきです。「AIはスクラッチデータベースは見られるが本番は見られない」と、何も切断せずに言えるようにしたい。これは最も過小評価されている制御の一つです。重要でないデータベースではAIに寛大に、重要なものでは厳格にできるからです。

破壊的操作の前の確認。 AIは意図的なステップなしにテーブルを削除したり行を消したりできてはいけません。それが書き込みを完全にブロックするモードでも確認プロンプトでも、要点は破壊が単一の無防備なツール呼び出しにならないことです。これはモデルが間違いを犯すから、そしてプロンプトインジェクションが現実だから重要です——AIがあなたのデータから敵対的なテキストを読んだとき、そのテキストがDROP TABLEに変わってほしくはありません。

localhost限定のバインド。 サーバーがHTTPを話すなら、0.0.0.0ではなく127.0.0.1にバインドすべきです。違いは、あなたのネットワーク上の他の誰かがそれに到達できるかどうかです。カフェのwifiネットワークでうっかり露出したデータベースMCPサーバーは、最悪の午後です。

監査とログの可視性。 AIが実際に実行したクエリを見られるべきです。何かおかしく見えるとき——予期しない書き込み、触るはずのない列に触れるクエリ——見るべき記録が欲しい。これを公開するサーバーはあなたにフィードバックループを与えており、しないサーバーは盲目的に信頼するよう求めています。

データベース対応。 あなたが実際に使うデータベースがサポートされ、よくサポートされているか確認しましょう。名目上「Postgresをサポート」するが拡張機能を持つスキーマで詰まるサーバーや、SQLiteの癖を扱えないサーバーは、混乱する失敗の仕方をするので、役立たず以下です。

レプリカに向けられるか？ AIのデータベースアクセスのための単一最良の堅牢化の動きは、プライマリではなく読み取りレプリカに接続することです。サーバーをレプリカに向けられるなら——あるいは単にレプリカ上で読み取り専用ユーザーを与えられるなら——モデルによる壊滅的な間違いでさえ本番データを傷つけられません。コピーで作業するデータベース版であり、私が最もよく与えるアドバイスです。

風景

製品リストではなくカテゴリで説明します。MCPエコシステムは、特定のリストがあなたが読む頃には古くなるほど速く動くからです。しかしカテゴリは安定しており、理解する価値があります。

特定のデータベース向けの公式およびコミュニティサーバー。 Postgres用、SQLite用、MySQL用のMCPサーバーがあり、プロトコル自身のコミュニティと独立した開発者の混ざりによってメンテナンスされています。それらは一般に接続文字列かファイルパスを取り、データベースに直接接続し、上記のクエリ／スキーマツールを公開します。通常オープンソースで監査可能であり、それは真の美徳です——それらが何をするかを正確に読めます。落とし穴は、そのほとんどが直接サーバーであることです。あなたの認証情報を保持し、動かす場所で動き、アクセス制御は最小限になりがちです。多くは堅牢な読み取り専用モードを持たず、ほとんどはソースごとのスコープや監査ログを与えません。使い捨てのデータベースに対するローカル開発には優れており、追加のラッピングなしには本番級のものには不向きです。

データベース接続をラップするホスト型の提供物。 これらがクラウドリレーです。このカテゴリには、製品全体が「あなたのデータベースをAIに接続する」サービスが含まれます——サインアップすると、彼らが接続を処理し、エンドポイントが得られます。品質は大きく異なり、セキュリティの姿勢はさらに大きく異なります。だからこそ上記のチェックリストが重要です。検討に値するのは、データの扱いについて正直で、読み取り専用とスコープの制御を提供し、認証情報とクエリ結果がどうなるかを平易な言葉で説明できるものです。

独自のローカルMCPサーバーを出荷するデスクトップツール。 これが最新のカテゴリで、私が最も近いもの——BaseVoltがここに属するからです。考え方は、データの閲覧と編集にすでに使っているデータベースツールが、その機能の一つとしてlocalhost上でMCPサーバーも動かすことです。ツールはすでにあなたの接続と認証情報を管理しているので、MCPサーバーはその管理を継承します——認証情報はアプリ内にローカルで暗号化されて留まり、AIクライアントはリモートエンドポイントではなくあなたのマシン上のプロセスと話します。

BaseVoltはmacOSとWindows向けのローカルファーストのデスクトップアプリで、PostgreSQL、MySQL、SQLite、Cloudflare D1に直接接続します。そのMCPサーバーはlocalhost上で動き——デフォルトエンドポイントはhttp://localhost:3107/mcp——ローカルなので、AIクライアントは第三者経由でリレーするのではなく、あなた自身のマシン上のプロセスと話します。読み取り専用モードとデータソースごとの制限をサポートするので、一つのデータベースをAIに公開し、別のものを完全に手の届かないところに保て、MCPツール呼び出しをログに記録するのでAIが実際に何をしたかを見られます。何もインストールせずにワークフロー全体をライブデモで見られます。

スタンドアロンのリレーを出荷するのではなく、このように作った理由はまさに認証情報の問題です。ツールはそもそも動くためにあなたのデータベース認証情報を保持しなければなりません——それがデータベースクライアントというものです。それにMCPサーバーを持たせれば、それらの認証情報を設定ファイルに複製したりベンダーに渡したりする必要がなくなります。AIクライアントはそれらを見ず、モデルも見ません。

AIをデータベースに接続する前のセキュリティチェックリスト

これは印刷しておきたい部分です。どれも珍しいものではありません。どれも見落としがちです。

読み取り専用ユーザーかレプリカから始める。 SELECTのみの権限を持つデータベースユーザーを作成するか、サーバーを読み取りレプリカに向けます。何よりも先にこれをしてください。このリストで単一最もてこの効くことであり、残りのリスク表面を劇的に小さくするからです。AIが書き込めなければ、最悪のケースは「データ損失」ではなく「モデルが見るべきでないものを見た」になります。
書き込みアクセスで本番に向けない。 デフォルトとしても、「テストのためだけ」も、5分間も。AIクライアントを通じた本番への書き込みアクセスは、一度しかできない間違いです。AIにスキーマ変更を手伝わせる必要があるなら、コピーに対して行ってください。
一つのデータベースにスコープする。 到達できるすべてをAIに渡さないでください。目の前のタスクに必要な特定のデータベースだけを公開し、他は何も。これは間違いの爆発半径と、モデルがさまよい込めるデータ量の両方を制限します。
可能な限りlocalhostに保つ。 サーバーがあなたのマシンで動けるなら、そこで動かしましょう。localhostに束縛されたサーバーはネットワークから到達できず、問題のクラス全体を取り除きます。理由があるときだけ——チーム共有、あるいはインストールできないマシン——リモートにし、そうするときはエンドポイントを意図的に保護してください。
クエリ結果をモデルが今持っているデータとして扱う。 これが人々が抵抗するメンタルモデルの転換です。結果セットがMCPサーバーを通って戻った瞬間、それらの行は会話コンテキストの一部であり、モデルプロバイダへ向かっています。列にチャットウィンドウに貼り付けないようなものが含まれるなら、それを選択しないでください。SELECT *ではなく明示的な列でSELECTし、不要なものを除外してください。
サーバーがログするものを見直す。 少なくとも最初は、クエリログを定期的に見てください。驚きを探しています——頼んでいない書き込み、AIが触ると思わなかったテーブル。決して読まないログは、ログがないのと同じです。
終わったら認証情報を取り消す。 AIアクセスのために専用ユーザーを立ち上げたなら、実験が終わったら削除してください。トークンを使ったなら、ローテーションしてください。目的のために作成された認証情報は、その目的を生き延びるべきではありません。次にそれを見つける人は、なぜ存在するのかわからないからです。

全体を貫くテーマは、AIが何に到達できるかを最小化すべきであり、単に誰がAIに到達できるかではないということです。MCPセキュリティについての会話のほとんどはサーバーを保護することについてです。より大きな利益は通常、サーバーが何に触れることを許されるかを制限することです。

選び方

ここまで読んだなら、私が実際にどう決めるかを紹介します。

あなたがソロ開発者か、気にかけるデータベースで作業する小規模チームなら、ローカルに行きましょう。 独自のローカルMCPサーバーを出荷するツールをインストールするか、ローカルのデータベースに対して直接サーバーを動かします。認証情報をマシン上に保ちましょう。マシンごとであることを受け入れましょう。小規模チームにはそのコストは些細だからです。これは最も良いセキュリティ姿勢と最も少ない継続メンテナンスを持つアーキテクチャで、圧倒的多数のユースケースをカバーします。

あなたの組織が共有された、マネージドな、監査可能なアクセスを必要とするなら、リモートに行きましょう——そして意図的に。 セルフホストしてホストと認証情報を所有するか、データの扱いを実際に読んだリレーを選びます。その前に本物の認証を置きましょう。読み取り専用ユーザーかレプリカを与えましょう。設定して忘れるエンドポイントではなく、オーナーのいる社内サービスとして扱いましょう。

ただ探検しているなら、最速のものを使いましょう。ただし使い捨てのデータベースで。 リレーのゼロセットアップ体験は、試しに触るときには真の利点です。ただ使い捨てのデータベースが静かに本番のものにならないように。アーキテクチャの決定が元に戻すのに高くつくようになるのは、まさに「楽しい実験」から「重要なツール」への移行のときです。

私が避ける唯一のことは、多くの人が決めずに陥るデフォルトです。最初のチュートリアルで、最初の試行でうまくいったから、書き込みアクセスで本番データベースに直結されたクラウドリレー。その組み合わせは便利で、私が最も動かしたくないものです。

まとめ

MCPデータベースサーバーは今や本当に役に立ち、重要な問いは使うかどうかではなく、接続がどこに存在するかです。クラウドリレーはゼロセットアップとチーム共有を買わせ、その代償を信頼で請求します。あなたの認証情報とクエリ結果が第三者を通過します。セルフホストのリモートサーバーはホストの制御を与えますが、ネットワークに面した認証表面を持つ常時稼働サービスのコストがかかります。ローカルMCPは認証情報とデータベース接続をあなた自身のマシン上に保ち、その代わりに簡単なチーム共有を諦めます。

単一の正しい答えはなく、あると言ったら嘘になります。しかし良いデフォルトはあります。可能な限り接続をローカルに保ち、重要なものすべての前に読み取り専用ユーザーかレプリカを置き、AIをそれが必要な一つのデータベースにスコープし、モデルが読んだものは何であれ今や知っていることを忘れないこと。この4つをやれば、アーキテクチャの問いはほとんど自ずと答えが出ます。

BaseVoltはこれのローカル端についての私の見解です——あなたのデータベースに直接接続し、独自のlocalhost MCPサーバーを動かすデスクトップアプリで、AIクライアントはリレーではなくあなたのマシン上のプロセスと話します。Hobby枠は永久に無料で、アカウント不要で2データソースをカバーし、Proはそれを超えるなら無制限のデータソースで年99ドルです。価格を見るか、ただ試せます——クレジットカード不要の14日間トライアルがあり、デモは何もインストールせずにワークフローを示します。

比較ではなくセットアップの手順が欲しいなら、ローカルMCPチュートリアルが端から端まで説明します。