Postgres Mcp について
Postgres MCP Pro は、開発からテスト、本番環境のチューニングまでを対象とするオープンソースの Postgres 向け MCP サーバーです。インデックスチューニング、EXPLAIN プラン分析、ヘルスチェック、設定可能な安全な SQL 実行を提供し、本番環境では読み取り専用モードで利用できます。
主な機能
- 01インデックスチューニングとインデックス推奨
- 02仮想インデックスを用いた EXPLAIN プラン分析
- 03データベースヘルスチェック
- 04スキーマを考慮した SQL 生成
- 05読み取り専用モードを含むアクセス制御
- 06stdio および SSE トランスポートへの対応
活用シーン
- 01遅いクエリの原因調査と最適化の提案取得
- 02データベースのワークロードに対するインデックス推奨
- 03本番環境での読み取り専用によるデータベース状態の確認
MCP 対応
本プロジェクトは MCP サーバーであり、list_schemas、execute_sql、explain_query、analyze_db_health などのツールを通じて、スキーマ参照、SQL 実行、パフォーマンス分析の機能を MCP クライアントに公開します。
設定
ローカルサーバーの設定はどのクライアントでも共通です。コピーしてクライアントの MCP 設定ファイルに貼り付けてください。
ツール
ローカルサーバーのツールはマシン上で起動して初めて取得できます。メンテナーはまだツール一覧を提供していません。
詳細
インデックスのチューニング、実行計画、ヘルスチェック、安全な SQL 実行に対応した Postgres MCP サーバーです。
概要
Postgres MCP Pro は、初期のコーディングからテスト、デプロイ、本番環境でのチューニングやメンテナンスまで、開発プロセス全体を通じて、ユーザーと AI エージェントを支援するために構築されたオープンソースの Model Context Protocol(MCP)サーバーです。
Postgres MCP Pro は、単にデータベース接続をラップするだけではありません。
主な機能は次のとおりです。
- 🔍 データベースの健全性 - インデックスの健全性、接続の使用状況、バッファーキャッシュ、バキュームの健全性、シーケンスの上限、レプリケーションの遅延などを分析します。
- ⚡ インデックスのチューニング - 実用レベルの強力なアルゴリズムを使って、何千ものインデックス候補を調べ、ワークロードに最適なものを見つけます。
- 📈 クエリプラン - EXPLAIN プランを確認し、仮想インデックスの影響をシミュレーションすることで、パフォーマンスを検証、最適化します。
- 🧠 スキーマインテリジェンス - データベーススキーマを詳細に把握し、コンテキストを考慮して SQL を生成します。
- 🛡️ 安全な SQL 実行 - 読み取り専用モードや安全な SQL 解析への対応を含む、設定可能なアクセス制御により、開発環境と本番環境の両方で利用できます。
Postgres MCP Pro は、さまざまな環境で柔軟に使えるよう、標準入力/標準出力(stdio)とServer-Sent Events(SSE)の両方のトランスポートに対応しています。
Postgres MCP Pro を開発した背景について詳しくは、公開時のブログ記事をご覧ください。
デモ
使い物にならない状態から、圧倒的な速さへ
- 課題: AI アシスタントを使って映画アプリを生成しましたが、SQLAlchemy ORM のコードがひどく遅く動作しました。
- 解決策: Cursor で Postgres MCP Pro を使い、数分でパフォーマンスの問題を解決しました。
実施したこと:
- 🚀 ORM クエリ、インデックス、キャッシュなどのパフォーマンスを改善
- 🛠️ エージェントにデータの調査、クエリの修正、関連コンテンツの追加を促し、壊れていたページを修正
- 🧠 データを調査して ORM クエリを修正し、より関連性の高い結果を表示することで、人気映画の表示を改善
以下の動画をご覧いただくか、手順の詳細をお読みください。
https://github.com/user-attachments/assets/24e05745-65e9-4998-b877-a368f1eadc13
クイックスタート
前提条件
開始する前に、次のものをご用意ください。
- データベースのアクセス認証情報。
- Docker または Python 3.12 以降。
アクセス認証情報
psql または pgAdmin などの GUI ツールを使って、アクセス認証情報が有効であることを確認できます。
Docker または Python
Docker と Python のどちらを使うかは自由に選べます。 Python を使う場合、環境に固有の問題が発生することがあるため、一般的には Docker をおすすめします。 ただし、使い慣れた方法を選ぶのが適している場合もよくあります。
インストール
Postgres MCP Pro をインストールするには、以下のいずれかの方法を選択してください。
オプション 1:Docker を使用する
Postgres MCP Pro の MCP サーバー Docker イメージをプルします。 このイメージには必要な依存関係がすべて含まれており、さまざまな環境で Postgres MCP Pro を確実に実行できます。
docker pull crystaldba/postgres-mcp
オプション 2:Python を使用する
pipx がインストールされている場合は、次のコマンドで Postgres MCP Pro をインストールできます。
pipx install postgres-mcp
それ以外の場合は、uv を使用して Postgres MCP Pro をインストールします。
uv pip install postgres-mcp
uv のインストールが必要な場合は、uv のインストール手順を参照してください。
AI アシスタントを設定する
Claude Desktop で Postgres MCP Pro を設定する手順を詳しく説明します。 多くの MCP クライアントには同様の設定ファイルがあるため、これらの手順をお使いのクライアントに合わせて調整できます。
Claude Desktop の設定
Postgres MCP Pro を追加するには、Claude Desktop の設定ファイルを編集する必要があります。 このファイルの場所はオペレーティングシステムによって異なります。
- MacOS:
~/Library/Application Support/Claude/claude_desktop_config.json - Windows:
%APPDATA%/Claude/claude_desktop_config.json
Claude Desktop の Settings メニュー項目から設定ファイルの場所を確認することもできます。
次に、設定ファイルの mcpServers セクションを編集します。
Docker を使用する場合
{
"mcpServers": {
"postgres": {
"command": "docker",
"args": [
"run",
"-i",
"--rm",
"-e",
"DATABASE_URI",
"crystaldba/postgres-mcp",
"--access-mode=unrestricted"
],
"env": {
"DATABASE_URI": "postgresql://username:password@localhost:5432/dbname"
}
}
}
}
Postgres MCP Pro の Docker イメージは、コンテナ内から機能するようにホスト名 localhost を自動的に再マッピングします。
- MacOS/Windows:
host.docker.internalを自動的に使用します - Linux:
172.17.0.1または適切なホストアドレスを自動的に使用します
uvx を使用する場合
{
"mcpServers": {
"postgres": {
"command": "uvx",
"args": [
"postgres-mcp",
"--access-mode=unrestricted"
],
"env": {
"DATABASE_URI": "postgresql://username:password@localhost:5432/dbname"
}
}
}
}
pipx を使用する場合
{
"mcpServers": {
"postgres": {
"command": "postgres-mcp",
"args": [
"--access-mode=unrestricted"
],
"env": {
"DATABASE_URI": "postgresql://username:password@localhost:5432/dbname"
}
}
}
}
uv を使用する場合
{
"mcpServers": {
"postgres": {
"command": "uv",
"args": [
"run",
"postgres-mcp",
"--access-mode=unrestricted"
],
"env": {
"DATABASE_URI": "postgresql://username:password@localhost:5432/dbname"
}
}
}
}
接続 URI
postgresql://... を、Postgres データベースの接続 URIに置き換えてください。
アクセスモード
Postgres MCP Pro は複数のアクセスモードをサポートしており、AI エージェントがデータベースに対して実行できる操作を制御できます。
- 無制限モード:データとスキーマを変更するための読み取り/書き込みアクセスをすべて許可します。開発環境に適しています。
- 制限モード:操作を読み取り専用トランザクションに制限し、リソースの使用量(現時点では実行時間のみ)に制約を設けます。本番環境に適しています。
制限モードを使用するには、上記の設定例で --access-mode=unrestricted を --access-mode=restricted に置き換えてください。
その他の MCP クライアント
多くの MCP クライアントには Claude Desktop と同様の設定ファイルがあるため、上記の例をお使いのクライアントに合わせて調整できます。
- Cursor を使用している場合は、
Command PaletteからCursor Settingsに移動し、MCPタブを開いて設定ファイルにアクセスできます。 - Windsurf を使用している場合は、
Command PaletteからOpen Windsurf Settings Pageに移動して設定ファイルにアクセスできます。 - Goose を使用している場合は、
goose configureを実行し、Add Extensionを選択します。 - Qodo Gen を使用している場合は、Chat パネルを開き、
Connect more tools、+ Add new MCPの順にクリックして、新しい設定を追加します。
SSE トランスポート
Postgres MCP Pro は SSE トランスポートをサポートしており、複数の MCP クライアントで 1 つのサーバー(リモートサーバーの場合もあります)を共有できます。
SSE トランスポートを使用するには、--transport=sse オプションを指定してサーバーを起動します。
たとえば、Docker では次のコマンドを実行します。
docker run -p 8000:8000 \
-e DATABASE_URI=postgresql://username:password@localhost:5432/dbname \
crystaldba/postgres-mcp --access-mode=unrestricted --transport=sse
次に、MCP クライアントの設定を更新して、MCP サーバーを呼び出すようにします。
たとえば、Cursor の mcp.json または Cline の cline_mcp_settings.json には、次のように記述できます。
{
"mcpServers": {
"postgres": {
"type": "sse",
"url": "http://localhost:8000/sse"
}
}
}
Windsurf の場合、mcp_config.json の形式は少し異なります。
{
"mcpServers": {
"postgres": {
"type": "sse",
"serverUrl": "http://localhost:8000/sse"
}
}
}
Postgres 拡張機能のインストール(任意)
インデックスのチューニングと包括的なパフォーマンス分析を有効にするには、データベースで pg_stat_statements と hypopg の拡張機能を読み込む必要があります。
pg_stat_statements拡張機能により、Postgres MCP Pro はクエリ実行統計を分析できます。 たとえば、実行速度が遅いクエリや、多くのリソースを消費しているクエリを把握できます。hypopg拡張機能により、インデックスを追加した後の Postgres クエリプランナーの動作をシミュレーションできます。
AWS RDS、Azure SQL、または Google Cloud SQL での拡張機能のインストール
Postgres データベースがクラウドプロバイダーのマネージドサービスで稼働している場合、pg_stat_statements と hypopg の拡張機能は、システムですでに利用可能になっているはずです。
この場合は、十分な権限を持つロールを使用して CREATE EXTENSION コマンドを実行するだけです。
CREATE EXTENSION IF NOT EXISTS pg_stat_statements;
CREATE EXTENSION IF NOT EXISTS hypopg;
セルフマネージド Postgres での拡張機能のインストール
Postgres を独自に管理している場合は、追加の作業が必要になることがあります。
pg_stat_statements 拡張機能を読み込む前に、Postgres の設定ファイルで shared_preload_libraries にこの拡張機能が記載されていることを確認する必要があります。
また、hypopg 拡張機能は、Postgres に常に同梱されているわけではないため、システムレベルでの追加インストール(パッケージマネージャーを使用するなど)が必要になる場合があります。
使用例
データベースの健全性の概要を取得する
質問:
データベースの健全性を確認して、問題があれば特定してください。
遅いクエリを分析する
質問:
データベースで最も遅いクエリは何ですか? また、どうすれば高速化できますか?
処理速度を上げるための推奨事項を取得する
質問:
アプリの動作が遅いです。どうすれば速くできますか?
インデックスの推奨事項を生成する
質問:
データベースのワークロードを分析して、パフォーマンスを改善するインデックスを提案してください。
特定のクエリを最適化する
質問:
次のクエリの最適化を手伝ってください:SELECT * FROM orders JOIN customers ON orders.customer_id = customers.id WHERE orders.created_at > '2023-01-01';
MCP サーバー API
MCP 標準では、ツール、リソース、プロンプトなど、さまざまな種類のエンドポイントが定義されています。
Postgres MCP Pro は、MCP ツールのみを通じて機能を提供します。 MCP クライアントのエコシステムでは、MCP ツールが広くサポートされているため、この方式を採用しました。 これは、Reference Postgres MCP Serverを含む他の Postgres MCP サーバーが、スキーマ情報を公開するためにMCP リソースを使用する方式とは異なります。
Postgres MCP Pro のツール:
| ツール名 | 説明 |
|---|---|
list_schemas | PostgreSQL インスタンスで利用可能なすべてのデータベーススキーマを一覧表示します。 |
list_objects | 指定したスキーマ内のデータベースオブジェクト(テーブル、ビュー、シーケンス、拡張機能)を一覧表示します。 |
get_object_details | 特定のデータベースオブジェクトに関する情報を提供します。たとえば、テーブルの列、制約、インデックスなどです。 |
execute_sql | データベースに対して SQL 文を実行します。制限モードで接続している場合は読み取り専用に制限されます。 |
explain_query | SQL クエリの実行計画を取得します。計画には、PostgreSQL による処理方法とクエリプランナーのコストモデルが示されます。仮想インデックスを指定して、インデックス追加後の動作をシミュレートすることもできます。 |
get_top_queries | pg_stat_statements のデータを使用し、合計実行時間に基づいて遅い SQL クエリを報告します。 |
analyze_workload_indexes | データベースのワークロードを分析してリソースを大量に消費するクエリを特定し、それらに最適なインデックスを推奨します。 |
analyze_query_indexes | 最大 10 件の特定の SQL クエリを分析し、それらに最適なインデックスを推奨します。 |
analyze_db_health | バッファーキャッシュのヒット率、接続の健全性、制約の検証、インデックスの健全性(重複、未使用、無効)、シーケンスの上限、バキュームの健全性など、包括的なヘルスチェックを実行します。 |
関連プロジェクト
Postgres MCP サーバー
- Query MCP。3 層の安全性アーキテクチャと Supabase 管理 API のサポートを備えた、Supabase Postgres 用 MCP サーバーです。
- PG-MCP。柔軟な接続オプション、実行計画、拡張機能のコンテキストなどを備えた、PostgreSQL 用 MCP サーバーです。
- Reference PostgreSQL MCP Server。スキーマ情報を MCP リソースとして公開し、読み取り専用クエリを実行する、シンプルな MCP サーバーの実装です。
- Supabase Postgres MCP Server。Supabase の管理機能を提供する MCP サーバーで、Supabase コミュニティによって積極的に保守されています。
- Nile MCP Server。Nile のマルチテナント Postgres サービスの管理 API にアクセスするための MCP サーバーです。
- Neon MCP Server。Neon のサーバーレス Postgres サービスの管理 API にアクセスするための MCP サーバーです。
- Wren MCP Server。Postgres やその他のデータベースでビジネスインテリジェンスを実現する、セマンティックエンジンを提供します。
DBA ツール(商用製品を含む)
- Aiven Database Optimizer。データベースのワークロードを包括的に分析し、クエリの最適化やその他のパフォーマンス改善を行うツールです。
- dba.ai。GitHub と連携してコードの問題を解決する、AI を活用したデータベース管理アシスタントです。
- pgAnalyze。パフォーマンスのボトルネックの特定、クエリの最適化、リアルタイムアラートに対応する、包括的なモニタリングおよび分析プラットフォームです。
- Postgres.ai。豊富な Postgres ナレッジベースと GPT-4 を組み合わせた、対話型チャット体験を提供します。
- Xata Agent。LLM を活用した推論とプレイブックを用いて、データベースの健全性を自動的に監視し、問題を診断して推奨事項を提示する、オープンソースの AI エージェントです。
Postgres ユーティリティ
- Dexter。PostgreSQL の仮想インデックスを生成・テストするツールです。
- PgHero。推奨事項を提示する、Postgres のパフォーマンスダッシュボードです。 Postgres MCP Pro には、PgHero のヘルスチェック機能が組み込まれています。
- PgTune。Postgres の設定を調整するためのヒューリスティックです。
よくある質問
Postgres MCP Pro は、他の Postgres MCP サーバーとどう違いますか? AI エージェントが Postgres データベースに対してクエリを実行できる MCP サーバーは数多くあります。 Postgres MCP Pro もそれを行いますが、Postgres データベースのパフォーマンスを理解し、改善するためのツールも追加しています。 たとえば、インデックスを自動調整するための最新の産業レベルのアルゴリズムである、Microsoft SQL Server のデータベースチューニングアドバイザーの Anytime Algorithm のバージョンを実装しています。
| Postgres MCP Pro | その他の Postgres MCP サーバー |
|---|---|
| ✅ 決定論的なデータベースのヘルスチェック | ❌ 再現性のない LLM 生成のヘルスクエリ |
| ✅ 理論に基づいたインデックス検索戦略 | ❌ 生成 AI によるインデックス改善の推測 |
| ✅ ワークロードを分析して主要な問題を特定 | ❌ 一貫性のない問題分析 |
| ✅ パフォーマンス改善をシミュレーション | ❌ 自分で試して、動作するか確かめる |
Postgres MCP Pro は、決定論的なツールと古典的な最適化アルゴリズムを加えることで、生成 AI を補完します。 両者を組み合わせることで、信頼性と柔軟性の両方を実現できます。
LLM が推論や SQL 生成などを行えるのに、なぜ MCP ツールが必要なのですか? LLM は、曖昧さや推論、自然言語を伴うタスクに非常に役立ちます。 しかし、手続き型コードと比べると、処理が遅く、コストが高く、非決定的であり、信頼性の低い結果を生成することもあります。 データベースのチューニングには、数十年にわたって開発され、効果が実証されている確立されたアルゴリズムがあります。 Postgres MCP Pro では、LLM と古典的な最適化アルゴリズム、その他の手続き型ツールを組み合わせ、双方の長所を活用できます。
Postgres MCP Pro はどのようにテストしていますか? Postgres MCP Pro の信頼性と正確性を確保するには、テストが不可欠です。 Postgres MCP Pro に課題を与え、幅広いシナリオで適切に動作することを確認できるように設計された、AI 生成の敵対的ワークロードのテストスイートを構築しています。
どのバージョンの Postgres がサポートされていますか? 現在、テストは Postgres 15、16、17 を中心に行っています。 Postgres 13 から 17 までのバージョンをサポートする予定です。
このプロジェクトは誰が作成しましたか? このプロジェクトは Crystal DBA が作成し、保守しています。
ロードマップ
TBD
皆さんのご要望は、私たちが開発するものを決めるうえで重要な原動力となります。 issue または pull request を作成して、実現してほしいことをお知らせください。 Discord からご連絡いただくこともできます。
技術的な注記
このセクションでは、Postgres MCP Pro の設計に影響した技術的な検討事項の概要を説明します。
インデックスのチューニング
開発者なら、インデックスの不足がデータベースのパフォーマンス問題の最も一般的な原因の一つであることをご存じでしょう。 インデックスは、クエリの実行に必要なデータを Postgres がすばやく見つけられるようにするアクセス手段を提供します。 テーブルが小さい場合、インデックスによる違いはほとんどありません。しかし、データ量が増えるにつれて、テーブルスキャンとインデックス検索のアルゴリズム計算量の差は大きくなります(通常は O(n) 対 O(log n) であり、複数のテーブルを結合する場合はさらに大きくなる可能性があります)。
Postgres MCP Pro での推奨インデックスの生成は、いくつかの段階を経て行われます。
-
チューニングが必要な SQL クエリを特定する。 特定の SQL クエリに問題があると分かっている場合は、そのクエリを指定できます。 Postgres MCP Pro は、ワークロードを分析してインデックスチューニングの対象を特定することもできます。 そのために、各クエリの実行時間とリソース消費を記録する
pg_stat_statements拡張機能を利用します。 クエリは、実行ごと、または累計でリソースを最も多く消費する場合、インデックスチューニングの候補になります。 現時点では、累積リソース消費量の代理指標として実行時間を使用していますが、アクセスされたブロック数やディスクから読み取られたブロック数など、特定のリソースを調べるのも有効かもしれません。analyze_query_workloadツールは、実行回数と平均実行時間のしきい値を設け、実行あたりの平均時間を使って低速なクエリに焦点を当てます。 エージェントはget_top_queriesを呼び出すこともできます。このツールは、実行時間を平均値と合計値のどちらで見るかを指定するパラメーターを受け取ります。その後、これらのクエリをanalyze_query_indexesに渡して、インデックスの推奨事項を取得します。高度なインデックスチューニングシステムでは、「ワークロード圧縮」を使って、ワークロード全体の特性を反映する代表的なクエリのサブセットを生成し、後続のアルゴリズムで扱う問題を縮小します。 Postgres MCP Pro は、同じテンプレートから生成されたクエリがひとつにまとまるように正規化することで、限定的な形のワークロード圧縮を行います。 各クエリを同じ重みで扱います。これは簡略化ですが、インデックスによる効果が大きい場合には有効です。
-
候補インデックスを生成する インデックスによる改善を目指す SQL クエリの一覧を用意したら、追加候補となるインデックスの一覧を生成します。 そのために SQL を解析し、フィルター、結合、グループ化、並べ替えで使用されている列を特定します。
考えられるすべてのインデックスを生成するには、Postgres が複数列インデックスをサポートしているため、これらの列の組み合わせを考慮する必要があります。 現在の実装では、考えられる複数列インデックスごとにランダムに選択した順列をひとつだけ含めています。 順列のパフォーマンスは同等であることが多いため、探索空間を縮小する目的でこのように簡略化しています。 ただし、この分野は今後改善したいと考えています。
-
最適なインデックス構成を探索する。 目標は、インデックスのパフォーマンス上の利点と、保存および保守にかかるコストとのバランスが最適になる組み合わせを見つけることです。
hypopg拡張機能が提供する「what if?」機能を使って、パフォーマンスの向上を推定します。 これにより、インデックス追加後に Postgres のクエリオプティマイザーがクエリをどのように実行するかをシミュレートし、実際の Postgres のコストモデルに基づく変化を報告します。課題のひとつは、クエリプランの生成には通常、クエリで使用される具体的なパラメーター値に関する情報が必要なことです。 検討対象のクエリを減らすために必要なクエリの正規化では、パラメーター定数が削除されます。 バインド変数を介して指定されるパラメーター値も、同様に利用できません。
この問題に対処するため、テーブル統計からサンプリングして、パラメーターとして渡せる現実的な定数を生成します。 バージョン 16 では、Postgres に汎用の explain プラン機能が追加されましたが、たとえば
LIKE句に関する制約があり、当実装にはその制約がありません。考えられるすべてのインデックスの組み合わせを評価することは、単純なケースでしか実現できないため、探索戦略が重要です。 さまざまなインデックス手法を最も大きく分ける要素のひとつが、この点です。 Microsoft の Anytime アルゴリズムの手法を応用し、貪欲探索戦略を採用しています。つまり、まずインデックスひとつで最適な解を見つけ、次にそれに追加してインデックスふたつの解を作るための最適なインデックスを見つけます。 時間の上限に達した場合、または探索を一巡しても最小改善しきい値の 10% を超える改善が得られなかった場合に、探索を終了します。
-
費用対効果分析。 パフォーマンスが向上するインデックスと、より多くの容量を必要とするインデックスという 2 つの選択肢を提示されたとき、どちらを選ぶべきかをどう判断すればよいでしょうか。 従来、インデックスアドバイザーはストレージの予算を求め、そのストレージ予算に対してパフォーマンスを最適化していました。 私たちもストレージ予算を採用しますが、最適化の過程全体を通じて費用対効果分析を行います。
私たちはこれを、パレートフロントに沿って点を選択する問題として捉えています。パレートフロントとは、ある品質指標を改善すると別の指標が必ず悪化するような選択肢の集合です。 理想的な世界では、ストレージのコストとパフォーマンス向上の便益を金銭的な観点で評価したいところです。 しかし、よりシンプルで実用的なアプローチがあります。それは相対的な観点で変化を見るというものです。 ほとんどの人は、ストレージコストが 2 倍になっても、パフォーマンスが 100 倍向上するのであれば価値があると考えるでしょう。 私たちの実装では、このしきい値を設定するための構成可能なパラメーターを使用しています。 デフォルトでは、パフォーマンス向上の対数(底 10)の変化が、スペースコストの対数の差の 2 倍であることを要求します。 これは、100 倍のパフォーマンス向上に対して最大 10 倍のスペース増加を許容するということになります。
私たちの実装は、Microsoft SQL Server にある Anytime Algorithm と最も密接に関連しています。 Postgres 向けの自動インデックス作成ツールである Dexter と比較して、私たちはより広い探索空間を探索し、異なるヒューリスティクスを使用しています。 これにより、実行時間が長くなる代わりに、より優れたソリューションを生成できます。
また、探索の各ラウンドで行われた作業も表示します。これには、各インデックスを追加する前後のクエリプランの比較が含まれます。 これにより、LLM はインデックスの推奨事項に応答する際に利用できる追加のコンテキストを得られます。
実験的機能: LLM によるインデックスチューニング
Postgres MCP Pro には、Optimization by LLM に基づく実験的なインデックスチューニング機能が含まれています。
可能なインデックス構成を探索するためにヒューリスティクスを使用する代わりに、データベーススキーマとクエリプランを LLM に提供し、インデックス構成を提案するよう求めます。
次に hypopg を使用して提案されたインデックスでのパフォーマンスを予測し、その結果を LLM にフィードバックして新たな提案セットを生成します。
複数ラウンドの反復でそれ以上改善が見られなくなるまで、このプロセスを繰り返します。
LLM によるインデックス最適化は、インデックスの探索空間が広い場合や、多数の列を持つインデックスを検討する必要がある場合に利点があります。
従来の探索ベースのアプローチと同様に、hypopg のパフォーマンス予測の精度に依存します。
LLM によるインデックス最適化を実行するには、OPENAI_API_KEY 環境変数を設定して OpenAI API キーを提供する必要があります。
データベースの健全性
データベースの健全性チェックでは、重大な問題につながる前に、チューニングの機会やメンテナンスの必要性を特定します。 今回のリリースでは、Postgres MCP Pro は PgHero のデータベース健全性チェックを直接取り入れています。 現在、これらのチェックの検証を進めており、将来的に拡張する可能性があります。
- インデックスの健全性。未使用のインデックス、重複したインデックス、肥大化したインデックスを検出します。肥大化したインデックスは、データベースページを非効率的に使用します。 Postgres の autovacuum は、デッドタプルを指すインデックスエントリをクリーンアップし、エントリを再利用可能としてマークします。ただし、インデックスページを圧縮することはないため、最終的にインデックスページに有効なタプル参照がほとんど含まれなくなることがあります。
- バッファーキャッシュヒット率。ディスクではなくバッファーキャッシュから処理されるデータベース読み取りの割合を測定します。 バッファーキャッシュヒット率が低い場合は調査が必要です。コスト効率がよくないことが多く、アプリケーションのパフォーマンス低下につながるためです。
- 接続の健全性。データベースへの接続数を確認し、その使用状況を報告します。 最大のリスクは接続数が上限に達することですが、アイドル状態またはブロック状態の接続が多い場合も問題の兆候となることがあります。
- VACUUM の健全性。VACUUM はさまざまな理由から重要です。 特に重要な理由の一つは、トランザクション ID の周回を防ぐことです。これが発生すると、データベースが書き込みを受け付けなくなる可能性があります。 Postgres のマルチバージョン同時実行制御(MVCC)メカニズムでは、トランザクションごとに一意のトランザクション ID が必要です。 ただし、Postgres はトランザクション ID に 32 ビット符号付き整数を使用するため、最大 20 億件のトランザクションを処理した後、トランザクション ID を再利用する必要があります。 そのため、過去のトランザクションのトランザクション ID を「凍結」し、それらすべてに遠い過去を示す特別な値を設定します。 レコードが初めてディスクに書き込まれるときは、トランザクション ID の範囲に対する可視性情報とともに書き込まれます。 これらのトランザクション ID を再利用する前に、Postgres はディスク上のレコードを更新し、再利用するトランザクション ID への参照を取り除くために「凍結」する必要があります。 このチェックでは、トランザクション ID の周回を防ぐために VACUUM が必要なテーブルを検出します。
- レプリケーションの健全性。プライマリとレプリカ間の遅延を監視し、レプリケーションの状態を確認し、レプリケーションスロットの使用状況を追跡して、レプリケーションの健全性を確認します。
- 制約の健全性。通常の動作中、Postgres は制約違反を引き起こすトランザクションを拒否します。 ただし、データの読み込み後やリカバリーの状況では、無効な制約が発生することがあります。このチェックでは、無効な制約がないかを確認します。
- シーケンスの健全性。最大値を超えるリスクがあるシーケンスを検出します。
Postgres クライアントライブラリ
Postgres MCP Pro は、非同期 I/O を使用して Postgres に接続するために psycopg3 を使用します。 内部では、psycopg3 は libpq ライブラリを使用して Postgres に接続します。これにより、Postgres の全機能にアクセスでき、Postgres コミュニティによって完全にサポートされている基盤実装を利用できます。
Python ベースの他の一部の MCP サーバーは asyncpg を使用しています。これは libpq への依存をなくし、インストールを簡素化できる可能性があります。
Asyncpg は psycopg3 よりもおそらく高速ですが、私たち自身では検証していません。
以前のベンチマークでは、より大きなパフォーマンス差が報告されています。これは、新しい psycopg3 が成熟するにつれて、その差を縮めてきたことを示唆しています。
これらの点を考慮し、asyncpg ではなく psycopg3 を選択しました。
将来的にこの判断を見直す可能性もあります。
接続の設定
Reference PostgreSQL MCP Serverと同様に、Postgres MCP Pro は起動時に Postgres の接続情報を受け取ります。 常に同じデータベースに接続するユーザーには便利ですが、データベースを切り替えるユーザーには面倒な場合があります。
別の方法として、PG-MCPでは、使用時に MCP ツールの呼び出しを通じて接続情報を渡します。 データベースを切り替えるユーザーにはこちらのほうが便利で、1 つの MCP サーバーで複数のエンドユーザーを同時にサポートできます。
どちらよりも優れた方法があるはずです。 どちらにもセキュリティ上の弱点があります。MCP クライアントの多くは MCP サーバーの設定を安全に保存しません(例外は Goose です)。また、MCP ツールを通じて渡された認証情報は LLM を経由し、チャット履歴に保存されます。 さらに、どちらの方法にも、状況によっては使い勝手に問題があります。
スキーマ情報
スキーマ情報ツールの目的は、正確で効率的な SQL を生成するために必要な情報を、呼び出し元の AI エージェントに提供することです。 たとえば、ユーザーが「過去 1 年間にサンフランシスコを出発し、パリに到着したフライトは何便ですか?」と尋ねたとします。 AI エージェントは、フライトを保存しているテーブル、出発地と到着地を保存している列、さらに空港コードと空港の所在地を対応付けるテーブルなどを見つける必要があります。
Postgres からこの情報を取得する SQL を LLM が一般に生成できるのに、なぜスキーマ情報ツールを提供するのでしょうか?
Claude を使った経験から、呼び出し元の LLM は Postgres システムカタログや情報スキーマ(ANSI 標準化されたデータベースメタデータビュー)をクエリして、Postgres のスキーマを調べる SQL を非常にうまく生成できることがわかっています。 しかし、他の LLM も同じように信頼性と能力を備えているかどうかはわかりません。
スキーマ情報は、MCP ツールではなく、MCP リソースを使って提供したほうがよいのでしょうか?
Reference PostgreSQL MCP Serverでは、ツールではなくリソースを使ってスキーマ情報を公開しています。 リソースの操作はファイルシステムの操作に似ているため、この方法は多くの点で自然です。 ただし、MCP クライアントのエコシステムでは、リソースのサポートはツールのサポートほど普及していません(クライアントの例を参照)。 また、MCP 標準ではリソースに AI エージェントとエンドユーザーの双方がアクセスできるとされていますが、一部のクライアントは人間によるリソースツリーの操作しかサポートしていません。
保護された SQL 実行
AI は、単純なミスから悪意のある攻撃者による高度な攻撃まで、さまざまな脅威からデータベースを保護するという長年の課題を増幅させます。 脅威が偶発的なものであれ悪意のあるものであれ、同様のセキュリティフレームワークが適用され、その目的は機密性、完全性、可用性の 3 つのカテゴリに分類されます。 利便性と安全性の間のよく知られた緊張関係も明らかであり、顕著です。
Postgres MCP Pro の保護された SQL 実行モードは、完全性に焦点を当てています。 MCP の文脈では、LLM が生成した SQL による損害、たとえば意図しないデータの変更や削除、あるいは組織の変更管理プロセスを回避する可能性のあるその他の変更を最も懸念しています。
完全性を提供する最も簡単な方法は、データベースに対して実行されるすべての SQL が読み取り専用であることを保証することです。 これを行う 1 つの方法は、読み取り専用アクセス権限を持つデータベースユーザーを作成することです。 これは優れたアプローチですが、実際には多くの人にとって煩わしいと感じられます。 Postgres には接続やセッションを読み取り専用モードにする方法が提供されていないため、Postgres MCP Pro は、読み書き可能な接続の上で読み取り専用の SQL 実行を保証するために、より複雑なアプローチを使用しています。
Postgres MCP は、データとスキーマの変更を防ぐ読み取り専用トランザクションモードを提供します。 Reference PostgreSQL MCP Server と同様に、保護された SQL 実行を提供するために読み取り専用トランザクションを使用します。
このメカニズムを堅牢にするには、SQL がなんらかの方法で読み取り専用トランザクションモードを回避しないことを保証する必要があります。たとえば、COMMIT や ROLLBACK ステートメントを発行してから新しいトランザクションを開始するなどです。
たとえば、LLM は ROLLBACK ステートメントを発行してから新しいトランザクションを開始することで、読み取り専用トランザクションモードを回避できます。
たとえば:
ROLLBACK; DROP TABLE users;
このようなケースを防ぐために、実行前に pglast ライブラリを使用して SQL を解析します。
commit または rollback ステートメントを含む SQL は拒否します。
ありがたいことに、PL/pgSQL や PL/Python を含む一般的な Postgres ストアドプロシージャ言語では、COMMIT や ROLLBACK ステートメントは許可されていません。
データベースで安全でないストアドプロシージャ言語が有効になっている場合、当社の読み取り専用保護は回避される可能性があります。
現在、Postgres MCP Pro はデータベースに対して 2 つのレベルの保護を提供しており、利便性と安全性のスペクトルの両極端にそれぞれ 1 つずつあります。
- 「Unrestricted」は最大限の柔軟性を提供します。 速度と柔軟性が最優先され、貴重または機密性の高いデータを保護する必要がない開発環境に適しています。
- 「Restricted」は柔軟性と安全性のバランスを提供します。 データベースが信頼できないユーザーに公開されており、貴重または機密性の高いデータを保護することが重要な本番環境に適しています。
Unrestricted モードは、Cursor の自動実行モードのアプローチと一致しており、AI エージェントは限られた人間の監督や承認のもとで動作します。 自動実行は、ミスの結果が小さく、データベースに貴重または機密性の高いデータが含まれておらず、必要に応じて再作成またはバックアップから復元できる開発環境に展開されることを想定しています。
Restricted モードは保守的に設計されており、不便であっても安全側に倒しています。 Restricted モードは読み取り専用操作に限定されており、長時間実行されるクエリがシステムパフォーマンスに影響を与えるのを防ぐために、クエリ実行時間を制限しています。 将来的には、Restricted モードが本番データベースで安全に使用できることを保証するための対策を追加する可能性があります。
Postgres MCP Pro の開発
以下の手順は、Postgres MCP Pro の開発に取り組みたい開発者、またはソースから Postgres MCP Pro をインストールしたいユーザー向けのものです。
Local Development Setup
-
Install uv:
curl -sSL https://astral.sh/uv/install.sh | sh -
Clone the repository:
git clone https://github.com/crystaldba/postgres-mcp.git cd postgres-mcp -
Install dependencies:
uv pip install -e . uv sync -
Run the server:
uv run postgres-mcp "postgres://user:password@localhost:5432/dbname"
コメント
AI アプリケーションが外部のツールやデータソースに統一的な方法で接続するためのオープンなプロトコルです。クライアントはモデルとの対話を担い、MCP サーバーはツール・リソース・プロンプトテンプレートを提供します。標準メッセージでやり取りするため、1 つのサーバーを複数のクライアントで再利用できます。