PostgreSQL MCP

概要

Postgres Pro は、初期コーディングからテストとデプロイメント、本番環境のチューニングとメンテナンスまで、開発プロセス全体を通じてユーザーと AI エージェントをサポートするために構築されたオープンソースの Model Context Protocol (MCP) サーバーです。

Postgres Pro は、データベース接続をラップする以上の機能を実行します。

機能は次のとおりです:

Postgres Pro を構築した理由に関する詳しい背景については、リリース時のブログ投稿をご覧ください。

デモ

使えない状態から超高速へ

課題: AIアシスタントを使用して映画アプリを生成しましたが、SQLAlchemy ORMコードの実行が非常に遅かったです
解決策: Postgres ProとCursorを使用することで、パフォーマンスの問題を数分で解決しました。

Cursor AI エージェントと Postgres Pro を使用して、次のことを行いました。

🚀 パフォーマンスの修正 - 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 Pro をインストールするには、次のいずれかの方法を選択します。

オプション1: Dockerを使用する

Postgres Pro MCPサーバーのDockerイメージをプルします。このイメージには必要な依存関係がすべて含まれており、さまざまな環境でPostgres Proを信頼性の高い方法で実行できます。

docker pull crystaldba/postgres-mcp

オプション2: Pythonを使用する

pipxがインストールされている場合は、次のコマンドで Postgres Pro をインストールできます。

pipx install postgres-mcp

それ以外の場合は、 uvを使用して Postgres Pro をインストールします。

uv pip install postgres-mcp

uvをインストールする必要がある場合は、 uv のインストール手順を参照してください。

AIアシスタントを設定する

Claude DesktopでPostgres Proを設定するための詳細な手順をご紹介します。多くのMCPクライアントは同様の設定ファイルを持っているため、これらの手順をお好みのクライアントに合わせて調整できます。

クロードデスクトップ構成

Postgres 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 Pro Docker イメージは、コンテナ内から動作するようにホスト名localhost自動的に再マップします。

MacOS/Windows: host.docker.internal自動的に使用します
Linux: 172.17.0.1または適切なホストアドレスを自動的に使用します

`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 Pro は複数のアクセスモードをサポートしており、AI エージェントがデータベースで実行できる操作を制御できます。

無制限モード：データとスキーマを変更するための完全な読み取り/書き込みアクセスを許可します。開発環境に適しています。
制限モード：操作を読み取り専用トランザクションに制限し、リソース使用率（現在は実行時間のみ）に制約を課します。本番環境に適しています。

制限モードを使用するには、上記の構成例で--access-mode=unrestrictedを--access-mode=restricted置き換えます。

その他のMCPクライアント

多くの MCP クライアントには Claude Desktop と同様の構成ファイルがあり、上記の例を任意のクライアントに合わせて調整することができます。

カーソルを使用している場合は、 Command PaletteからCursor Settingsに移動し、 MCPタブを開いて構成ファイルにアクセスできます。
Windsurf を使用している場合は、 Command PaletteからOpen Windsurf Settings Page構成ファイルにアクセスできます。
Goose を使用している場合は、 goose configureを実行し、 Add Extensionを選択します。

Postgres拡張機能のインストール（オプション）

インデックスチューニングと包括的なパフォーマンス分析を有効にするには、データベースにpg_statementsおよびhypopg拡張機能をロードする必要があります。

pg_statements拡張機能を使用すると、Postgres Proはクエリ実行統計を分析できます。例えば、どのクエリの実行速度が遅いか、または多くのリソースを消費しているかを把握できます。
hypopg拡張機能により、Postgres Pro はインデックスを追加した後の Postgres クエリプランナーの動作をシミュレートできます。

AWS RDS、Azure SQL、またはGoogle Cloud SQLに拡張機能をインストールする

Postgresデータベースがクラウドプロバイダーのマネージドサービス上で実行されている場合、 pg_statementsとhypopg拡張機能は既にシステム上で利用可能になっているはずです。この場合、十分な権限を持つロールを使用してCREATE EXTENSIONコマンドを実行するだけで済みます。

CREATE EXTENSION IF NOT EXISTS pg_statements;
CREATE EXTENSION IF NOT EXISTS hypopg;

セルフマネージドPostgresへの拡張機能のインストール

ご自身でPostgresのインストールを管理されている場合は、追加の作業が必要になる場合がありますpg_statements拡張機能をロードする前に、Postgres設定ファイルのshared_preload_librariesにpg_statements拡張機能が含まれていることを確認してください。また、 hypopg拡張機能はPostgresに同梱されていないため、システムレベルでの追加インストール（パッケージマネージャー経由など）が必要になる場合があります。

使用例

データベースの健全性の概要を取得する

聞く：

データベースの健全性をチェックし、問題を特定します。

遅いクエリを分析する

聞く：

データベース内で最も遅いクエリは何ですか？どうすれば高速化できますか？

スピードアップのためのアドバイスを入手

聞く：

アプリが遅いです。どうすれば速くできますか？

インデックス推奨事項を生成する

聞く：

データベースのワークロードを分析し、パフォーマンスを向上させるためのインデックスを提案します。

特定のクエリを最適化する

聞く：

このクエリの最適化を手伝ってください: SELECT * FROM orders JOIN customers ON orders.customer_id = customers.id WHERE orders.created_at > '2023-01-01';

MCP サーバー API

MCP 標準では、ツール、リソース、プロンプトなど、さまざまな種類のエンドポイントが定義されています。

Postgres Proは、 MCPツールのみで機能を提供します。MCPクライアントエコシステムがMCPツールを広くサポートしているため、このアプローチを選択しました。これは、MCPリソースを使用してスキーマ情報を公開するリファレンスPostgres MCPサーバーを含む他のPostgres MCPサーバーのアプローチとは対照的です。

Postgres 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`	特定の SQL クエリのリスト (最大 10 個) を分析し、最適なインデックスを推奨します。
`analyze_db_health`	バッファキャッシュヒット率、接続の健全性、制約の検証、インデックスの健全性 (重複/未使用/無効)、シーケンス制限、バキュームの健全性など、包括的な健全性チェックを実行します。

よくある質問

Postgres Proは他のPostgres MCPサーバーとどう違うのでしょうか？ AIエージェントがPostgresデータベースに対してクエリを実行できるMCPサーバーは数多くあります。Postgres Proも同様の機能を備えていますが、Postgresデータベースのパフォーマンスを把握し、改善するためのツールも追加されています。例えば、Postgres Proは、 Microsoft SQL ServerのデータベースチューニングアドバイザーのAnytimeアルゴリズム（最新の強力な自動インデックスチューニングアルゴリズム）のバージョンを実装しています。

ポストグレプロ	その他のPostgres MCPサーバー
✅ 決定論的なデータベースヘルスチェック	❌ LLM が生成した再現不可能なヘルスクエリ
✅ 原則的なインデックス検索戦略	❌ Gen-AIがインデックスの改善を推測
✅ 主要な問題を見つけるためのワークロード分析	❌ 一貫性のない問題分析
✅ パフォーマンスの向上をシミュレートします	❌ 自分で試してみて、うまくいくかどうか確認しましょう

Postgres Pro は、決定論的ツールと従来の最適化アルゴリズムを追加することで、生成 AI を補完します。この組み合わせは信頼性が高く、柔軟性も高くなります。

LLMで推論やSQL生成などが可能なのに、なぜMCPツールが必要なのでしょうか？ LLMは、曖昧性、推論、自然言語を扱うタスクに非常に役立ちます。しかし、手続き型コードと比較すると、処理速度が遅く、コストが高く、非決定性があり、信頼性の低い結果を生成する場合もあります。データベースチューニングに関しては、数十年かけて開発され、効果が実証されている確立されたアルゴリズムがあります。Postgres Proでは、LLMを従来の最適化アルゴリズムやその他の手続き型ツールと組み合わせることで、両方の長所を活かすことができます。

Postgres Proはどのようにテストしていますか？ Postgres Proの信頼性と正確性を確保するには、テストが不可欠です。私たちは、Postgres Proにチャレンジさせ、様々なシナリオでパフォーマンスを発揮することを保証するために、AI生成による敵対的ワークロードスイートを構築しています。

*どのバージョンの Postgres がサポートされていますか?*現在、テストは Postgres 15、16、17 に重点を置いています。Postgres バージョン 13 から 17 をサポートする予定です。

*このプロジェクトを作成したのは誰ですか?*このプロジェクトはCrystal DBAによって作成および管理されています。

ロードマップ

未定

皆様と皆様のニーズは、私たちが開発する上で非常に重要な原動力です。Issueまたはプルリクエストを作成して、ご要望をお聞かせください。Discord でもお問い合わせいただけます。

テクニカルノート

このセクションには、Postgres Pro の設計に影響を与えた技術的な考慮事項の概要が記載されています。

インデックスチューニング

開発者は、インデックスの欠落がデータベースパフォーマンスの問題の最も一般的な原因の一つであることを知っています。インデックスは、Postgresがクエリ実行に必要なデータを迅速に見つけるためのアクセス方法を提供します。テーブルが小さい場合、インデックスによる影響はほとんどありませんが、データのサイズが大きくなるにつれて、テーブルスキャンとインデックス検索のアルゴリズムの複雑さの差は顕著になります（通常はO ( n ) vs O ( log n )ですが、複数のテーブルを結合する場合はさらに大きくなる可能性があります）。

Postgres Pro での推奨インデックスの生成は、いくつかの段階で進行します。

チューニングが必要なSQLクエリを特定します。特定のSQLクエリに問題があることが分かっている場合は、そのクエリを指定できます。Postgres Proはワークロードを分析し、インデックスのチューニング対象を特定することもできます。そのために、各クエリの実行時間とリソース消費量を記録するpg_stat_statements拡張機能が利用されています。クエリが実行単位または集計でリソース消費量が最も多い場合、そのクエリはインデックスチューニングの候補となります。現在、累積リソース消費量の代理指標として実行時間を使用していますが、アクセスされたブロック数やディスクから読み取られたブロック数など、具体的なリソースを調べることも有効です。analyze_query_workload ツールは、実行回数と平均実行時間analyze_query_workloadしきい値を設定し、実行単位の平均実行時間を使用して、遅いクエリに焦点を当てています。エージェントは、平均実行時間と合計実行時間のパラメータを受け入れるget_top_queriesを呼び出し、これらのクエリをanalyze_query_indexesに渡すことで、インデックスの推奨事項を取得できます。高度なインデックスチューニングシステムでは、「ワークロード圧縮」を用いて、ワークロード全体の特性を反映したクエリの代表的なサブセットを生成し、下流のアルゴリズムにおける問題を軽減します。Postgres Proは、同じテンプレートから生成されたクエリを1つのクエリとして扱うように正規化することで、限定的なワークロード圧縮を実現します。各クエリに均等に重み付けすることで、インデックス作成のメリットが大きい場合に有効な簡素化を実現します。
候補インデックスの生成インデックス作成によって改善したいSQLクエリのリストができたら、追加する可能性のあるインデックスのリストを生成します。そのためには、SQLを解析し、フィルター、結合、グループ化、並べ替えに使用されている列を特定します。Postgresはマルチカラムインデックスをサポートしているため、すべての可能なインデックスを生成するには、これらの列の組み合わせを考慮する必要があります。現在の実装では、各可能なマルチカラムインデックスについて、ランダムに選択される順列を1つだけ含めています。順列は多くの場合同等のパフォーマンスを示すため、この簡略化は検索空間を削減するために行っています。しかし、この領域は今後改善していく予定です。
最適なインデックス構成を探します。私たちの目標は、パフォーマンスの向上とインデックスの保存および維持にかかるコストのバランスが最適となるインデックスの組み合わせを見つけることです。hypopg hypopg機能が提供する「what if?」機能を用いて、パフォーマンスの向上を推定します。この機能は、インデックス追加後のPostgresクエリオプティマイザによるクエリ実行をシミュレートし、実際のPostgresコストモデルに基づいて変更内容を報告します。一つの課題は、クエリプランを生成するには、通常、クエリで使用される特定のパラメータ値を把握する必要があることです。クエリの正規化は、対象となるクエリを減らすために必要であり、パラメータ定数は削除されます。バインド変数で提供されるパラメータ値も同様に利用できません。この問題に対処するため、テーブル統計からサンプリングすることで、パラメータとして提供できる現実的な定数を生成します。Postgresバージョン16では、汎用実行計画機能が追加されましたが、 LIKE句などに制限があり、私たちの実装にはそれが含まれていません。検索戦略は非常に重要です。なぜなら、単純な状況でのみ実行可能なすべてのインデックスの組み合わせを評価する必要があるからです。これが、様々なインデックス作成手法を最も区別する点です。MicrosoftのAnytimeアルゴリズムのアプローチを応用し、貪欲な検索戦略を採用しています。つまり、最適な1インデックス解を見つけ、次にそれに追加する最適なインデックスを見つけて、2インデックス解を生成します。探索は、時間予算を使い果たした場合、または探索ラウンドで最小改善しきい値である10%を超える改善が得られなかった場合に終了します。
費用対効果分析。2つのインデックス作成方法があり、一方はパフォーマンスが高く、もう一方はより多くのスペースを必要とする場合、どちらを選択するかをどのように決定するでしょうか？従来、インデックスアドバイザーはストレージ予算を尋ね、そのストレージ予算に応じてパフォーマンスを最適化します。私たちもストレージ予算を考慮しますが、最適化の過程全体を通して費用対効果分析を実施します。私たちはこれを、パレート最適解に沿った点を選択する問題として捉えています。パレート最適解とは、ある品質指標を改善すると必然的に別の品質指標が悪化する選択肢の集合です。理想的な世界では、ストレージのコストとパフォーマンス向上によるメリットを金銭面で評価したいと考えるかもしれません。しかし、よりシンプルで実際的なアプローチがあります。それは、変化を相対的に見ることです。ほとんどの人は、ストレージコストが 2 倍になったとしても、パフォーマンスが 100 倍向上すれば価値があると同意するでしょう。私たちの実装では、このしきい値を設定するために設定可能なパラメータを使用しています。デフォルトでは、パフォーマンス向上の対数 (底 10) の変化が、スペースコストの対数の差の 2 倍になる必要があります。つまり、スペースを最大 10 倍増やしても、パフォーマンスが 100 倍向上することになります。

私たちの実装は、Microsoft SQL ServerのAnytimeアルゴリズムに最も密接に関連しています。Postgresの自動インデックス作成ツールであるDexterと比較すると、より広い空間を探索し、異なるヒューリスティックを用いています。これにより、実行時間は長くなりますが、より優れた解を生成することができます。

また、各検索ラウンドで行われた作業内容も表示します。これには、各インデックスの追加前後のクエリプランの比較も含まれます。これにより、LLMはインデックス作成の推奨事項に対応する際に使用できる追加のコンテキストを得ることができます。

データベースの健全性

データベースヘルスチェックは、重大な問題につながる前に、チューニングの必要性やメンテナンスの必要性を特定します。現在のリリースでは、Postgres ProはPgHeroから直接データベースヘルスチェックを採用しています。現在、これらのチェックの完全な検証に取り組んでおり、将来的には拡張していく予定です。

インデックスの健全性。未使用のインデックス、重複したインデックス、肥大化したインデックスを探します。肥大化したインデックスはデータベースページを効率的に使用しません。Postgresの自動バキュームは、不要なタプルを指すインデックスエントリをクリーンアップし、それらのエントリを再利用可能としてマークします。ただし、インデックスページを圧縮することはないため、最終的にはインデックスページに含まれる有効なタプル参照がほとんどなくなる可能性があります。
バッファキャッシュヒット率。ディスクではなくバッファキャッシュから提供されるデータベース読み取りの割合を測定します。バッファキャッシュヒット率が低い場合、コストが最適化されないことが多く、アプリケーションのパフォーマンス低下につながるため、調査が必要です。
接続の健全性。データベースへの接続数を確認し、その使用状況を報告します。最大のリスクは接続不足ですが、アイドル状態またはブロックされた接続の数が多い場合も、問題を示している可能性があります。
バキュームの健全性。バキュームは多くの理由で重要です。特に重要な理由の一つは、データベースが書き込みを受け付けなくなる原因となるトランザクションIDのラップアラウンドを防ぐことです。Postgresのマルチバージョン同時実行制御（MVCC）メカニズムでは、各トランザクションに一意のトランザクションIDが必要です。しかし、PostgresはトランザクションIDに32ビット符号付き整数を使用しているため、最大20億回のトランザクション後にはトランザクションIDを再利用する必要があります。このため、Postgresは過去のトランザクションのトランザクションIDを「フリーズ」し、それらをすべて遠い過去を示す特別な値に設定します。レコードが最初にディスクに書き込まれる際、それらは特定の範囲のトランザクションIDに対して可視性を持つように書き込まれます。これらのトランザクションIDを再利用する前に、Postgresはディスク上のレコードを更新し、「フリーズ」することで、再利用するトランザクションIDへの参照を削除する必要があります。このチェックは、トランザクションIDのラップアラウンドを防ぐためにバキューム処理が必要なテーブルを探します。
レプリケーションの健全性。プライマリとレプリカ間の遅延を監視し、レプリケーションの状態を確認し、レプリケーションスロットの使用状況を追跡することで、レプリケーションの健全性をチェックします。
制約の健全性。通常の動作中、Postgresは制約違反を引き起こす可能性のあるトランザクションをすべて拒否します。ただし、データのロード後やリカバリシナリオでは、無効な制約が発生する可能性があります。このチェックは、無効な制約を検出します。
シーケンスの健全性。最大値を超えるリスクがあるシーケンスを探します。

Postgres クライアントライブラリ

Postgres Proは、非同期I/Oを使用してPostgresに接続するためにpsycopg3を使用します。psycopg3は内部的にlibpqライブラリを使用してPostgresに接続し、Postgresの完全な機能セットと、Postgresコミュニティによって完全にサポートされている基盤実装へのアクセスを提供します。

PythonベースのMCPサーバーの中には、 libpqの依存を排除することでインストールを簡素化できる可能性のあるasyncpgを使用しているものもあります。asyncpgはpsycopg3よりも高速である可能性も高いですが、これは私たち自身で検証したものではありません。古いベンチマークではパフォーマンスの差が大きいことが報告されており、新しいpsycopg3は成熟するにつれてその差を縮めていることを示唆しています。

これらの考慮事項をバランスよく考慮した結果、 asyncpgではなくpsycopg3を選択しました。この決定は将来的に変更される可能性があります。

接続構成

リファレンスPostgreSQL MCPサーバーと同様に、Postgres Proは起動時にPostgresの接続情報を取得します。これは、常に同じデータベースに接続するユーザーにとっては便利ですが、データベースを切り替える際には煩雑になる可能性があります。

PG-MCPが採用している代替アプローチは、使用時にMCPツール呼び出しを介して接続情報を提供するというものです。これは、データベースを切り替えるユーザーにとってより便利であり、単一のMCPサーバーで複数のエンドユーザーを同時にサポートできます。

これらよりも優れたアプローチがあるはずです。どちらもセキュリティ上の弱点があり、MCPサーバーの設定を安全に保存しているMCPクライアントは少なく（Gooseは例外）、MCPツール経由で提供された認証情報はLLMを経由してチャット履歴に保存されます。また、どちらも一部のシナリオではユーザビリティの問題があります。

スキーマ情報

スキーマ情報ツールの目的は、呼び出し元のAIエージェントに、正確でパフォーマンスの高いSQLを生成するために必要な情報を提供することです。例えば、ユーザーが「過去1年間にサンフランシスコからパリに着陸したフライトは何便ありましたか？」と質問したとします。AIエージェントは、フライト情報を格納するテーブル、出発地と目的地を格納する列、そしておそらく空港コードと空港所在地をマッピングするテーブルを見つける必要があります。

LLM は通常、この情報を Postgres から直接取得するための SQL を生成できるのに、なぜスキーマ情報ツールを提供するのでしょうか?

Claude を使用した経験から、呼び出し側 LLM は、Postgres システムカタログと情報スキーマ（ANSI 標準のデータベースメタデータビュー）を照会することで、Postgres スキーマを探索するための SQL を生成するのに非常に優れていることがわかりました。ただし、他の LLM も同様に信頼性と性能に優れているかどうかは不明です。

MCP ツールではなく、 MCP リソースを使用してスキーマ情報を提供する方がよいでしょうか?

リファレンスPostgreSQL MCPサーバーは、ツールではなくリソースを使用してスキーマ情報を公開します。リソースのナビゲーションはファイルシステムのナビゲーションに似ているため、このアプローチは多くの点で自然です。しかし、MCPクライアントエコシステムでは、リソースのサポートはツールのサポートほど普及していません（クライアントの例を参照）。さらに、MCP標準ではリソースへのアクセスはAIエージェントとエンドユーザーのどちらでも可能とされていますが、一部のクライアントではリソースツリーのナビゲーションを人間のみでサポートしています。

保護されたSQL実行

AIは、単純なミスから悪意のある者による高度な攻撃に至るまで、様々な脅威からデータベースを保護するという長年の課題をさらに深刻化させます。脅威が偶発的なものであれ悪意のあるものであれ、機密性、完全性、可用性という3つのカテゴリーに分けられる目標を掲げた、同様のセキュリティフレームワークが適用されます。利便性と安全性の間には、お馴染みの緊張関係が顕著に表れています。

Postgres Proの保護されたSQL実行モードは整合性を重視しています。MCPの観点から最も懸念されるのは、LLMによって生成されたSQLが損害を引き起こすことです。例えば、意図しないデータの変更や削除、あるいは組織の変更管理プロセスを回避する可能性のあるその他の変更などです。

整合性を確保する最も簡単な方法は、データベースに対して実行されるすべてのSQLを読み取り専用にすることです。その方法の一つとして、読み取り専用アクセス権限を持つデータベースユーザーを作成することが挙げられます。これは優れたアプローチですが、実際には面倒だと感じる人も多いでしょう。Postgresには接続またはセッションを読み取り専用モードに設定する機能がありません。そのため、Postgres Proでは、より複雑なアプローチを採用し、読み取り/書き込み接続上で読み取り専用のSQL実行を保証します。

Postgresは、データとスキーマの変更を防止する読み取り専用トランザクションモードを提供します。リファレンスPostgreSQL MCPサーバーと同様に、読み取り専用トランザクションを使用して保護されたSQL実行を提供します。

このメカニズムを堅牢にするには、SQL が読み取り専用トランザクションモードを回避しないようにする必要があります。たとえば、 COMMITまたはROLLBACKステートメントを発行してから新しいトランザクションを開始するなどです。

例えば、LLMはROLLBACK文を発行して新しいトランザクションを開始することで、読み取り専用トランザクションモードを回避できます。例:

ROLLBACK; DROP TABLE users;

このような事態を防ぐため、 pglastライブラリを用いて実行前にSQLを解析します。 commitまたはrollback文を含むSQLはすべて拒否されます。幸いなことに、PL/pgSQLやPL/Pythonといった一般的なPostgresストアドプロシージャ言語では、 COMMIT文やROLLBACK文は使用できません。データベースで安全でないストアドプロシージャ言語が有効になっている場合、読み取り専用保護が回避される可能性があります。

現在、Postgres Pro は、利便性と安全性の両極に位置する 2 つのレベルのデータベース保護を提供しています。

「無制限」は最大限の柔軟性を提供します。スピードと柔軟性が最優先され、貴重なデータや機密データを保護する必要がない開発環境に適しています。
「制限付き」は柔軟性と安全性のバランスを実現します。データベースが信頼できないユーザーに公開され、貴重なデータや機密データの保護が重要な本番環境に適しています。

無制限モードは、Cursorの自動実行モードのアプローチと一致しており、AIエージェントは人間による監視や承認を限定的に受けながら動作します。自動実行モードは、ミスによる影響が少なく、データベースに貴重なデータや機密データが含まれず、必要に応じてデータベースを再作成またはバックアップから復元できる開発環境で導入されることを想定しています。

制限モードは、たとえ不便ではあっても安全性を最優先に考えた保守的な設計となっています。制限モードでは読み取り専用操作のみに制限され、長時間実行されるクエリがシステムパフォーマンスに影響を与えないようにクエリ実行時間も制限されています。今後、本番環境のデータベースで制限モードを安全に使用できるよう、対策を追加する可能性があります。

Postgres Pro 開発

以下の手順は、Postgres Pro で作業したい開発者、またはソースから Postgres Pro をインストールすることを好むユーザーを対象としています。

ローカル開発のセットアップ

uvをインストールします:
curl -sSL https://astral.sh/uv/install.sh | sh
リポジトリをクローンします:
git clone https://github.com/crystaldba/postgres-mcp.git cd postgres-mcp
依存関係をインストールします:
uv pip install -e . uv sync
サーバーを実行します:
uv run postgres-mcp "postgres://user:password@localhost:5432/dbname"

Integrations

概要

デモ