本番データベースへの接続が不要なPostgreSQL MCPサーバー。
dryrun はAIエージェント、IDE、CIに完全なスキーマ認識を提供します。ライブデータベース接続ではなく、オフラインのスナップショットから取得します。スキーマのlint、クエリの検証、マイグレーション安全性のチェック、外部キーグラフの探索が可能です。そして、資格情報がDBAのマシンの外に出ることは一切ありません。
dryrun は boringSQL スイートの一部であり、RegreSQL や Fixturize と並んでいます。
LLM/AIコーディングアシスタントは、コードやSQLクエリを書くのが非常に得意です。しかし、彼らは盲目です。あなたのスキーマ、インデックス、制約を理解していません。彼らは、最も忙しいテーブルに対して ACCESS EXCLUSIVE ロックをかけるマイグレーションを生成し、アプリをダウンさせるかもしれません。
一部のPostgreSQL MCPサーバーは、データベース接続情報を要求します。そして管理タスクを実行するにはSUPERUSER権限が必要かもしれません。それは問題を招くようなものです。
私たちはこの結果すでに目にしています。読み取り専用であるはずの MCPサーバーにおけるSQLインジェクション や、AIエージェントによる本番データベースの消去 という形で、この状況がどこに至るかを見ています。
モデルはデータベースを照会する必要はありません。スキーマを理解する必要があります。構造、制約、統計情報、バージョン固有の動作を理解する必要があります。その知識は構造的なものです。クエリの間ではなく、マイグレーションをデプロイしたときに変わるのです。
Related MCP server: pg-lens-mcp
dryrun は2つのものとして動作します： CLIツール と MCPサーバー です。CLIはスキーマを抽出し解析します。MCPサーバーはその解析をAIアシスタントに公開します。これらは意図的に分離されています。
CLIはPostgreSQLデータベースに接続し、完全なカタログ（テーブル、ビュー、インデックス、制約、パーティション、関数、列挙型、RLSポリシー、トリガー、拡張、GUC）をイントロスペクトし、スナップショットを .dryrun/history.db に書き込みます。そのスナップショットが、他のすべての要素の信頼できる情報源です。
スナップショットがあれば、CLIはオフラインで動作します：
Lint - 20以上の規約ルール（命名、型、主キー、タイムスタンプ、パーティショニング）と13の構造的監査ルール（重複インデックス、FKカバレッジ、循環的なFK、バキュームチューニング）
マイグレーション安全性 - ロックタイプの解析、所要時間の見積もり、テーブル再構築の検出、各DDL文に対する安全な代替案
クエリ検証 - libpg_queryによるSQL解析、実際のスキーマに対するカラム参照チェック、逆パターン検検出
スナップショット差分 - スナップショット間のスキーマ、プランナ統計、アクティビティを比較、ライブデータベースとの差分を検出
クエリ統計 - ノードごとの pg_stat_statements を取得し、ORMクエリのバリアントを形状に集約し、2つのキャプチャを比較して新しいクエリや遅延クエリを表面化
マルチノード統計 - レプリカごとの統計、seq_scanのホットスポット、ルーティングの不均衡
MCPサーバーは同じスナップショットを読み取ります。stdioまたはSSEを介して14個のツールを公開します：スキーマ探索、クエリ検証、プラン解析、マイグレーションチェック、lint、バキュームの健康状態、取得した pg_stat_statements の上位クエリ。ライブデータベースに接続すると、さらに3つ（explain_query、check_drift、columnar_report）が追加されます。AIアシスタントがSQLを書いている間、データベースを理解できます。
データベース接続は不要です。アシスタントが資格情報を見ることはありません。
スキーマコンテキストは、ライブ接続ではなくファイルに属します。 カラム型、行見積もり、インデックス定義、FK関係、PostgreSQLバージョンは、すべて一度エクスポートしてリポジトリにコミットできます。データベースアクセスを持つ一人がスキーマをダンプします。それ以外の全員、人間とAIエージェントを含めて、資格情報なしで完全なスキーマインテリジェンスを得られます。
資格情報はDBAのマシンから出るべきではありません。 MCPサーバーが何か役立つことをするのに DATABASE_URL を必要とするなら、それを使うすべての開発者が本番資格情報を必要とします。それはAIとは関係のないセキュリティ問題です。
サーバーは分析を行うべきであり、パススルーであってはなりません。 生の \d+ 出力を返しても、チャットに自分で貼り付けるのと大差ありません。価値は、そのデータを解釈することにあります。つまり、あなたのPostgreSQLバージョンに対してマイグレーションが安全かを確認し、FKインデックスの欠落を警告し、カラム参照を実際のスキーマに対して検証することです。
Homebrew：
Homebrew 6.0では、サードパーティのタップの信頼が必要になるれる前にフォーミュラを読み込みません：
brew trust --tap boringsql/boringsql
brew install boringsql/boringsql/dryrunHomebrew 5.x以前では、brew trust ステップをスキップしてください。タップ全体を信頼しない場合は、brew trust --formula boringsql/boringsql/dryrun でフォーミュラだけを信頼します。
npm / npx：
すでにNodeを持っているなら、dryrun は何もインストールせずに実行できます：
npx @boringsql/dryrun --versionこれにより、あなたのプラットフォーム（darwin-arm64、linux-x64、linux-arm64）用のプレビルドバイナリが取得、キャッシュされ、バージョンが表示されます。dryrun を恒久的にPATHに置くには：
npm install -g @boringsql/dryrun
dryrun --versionnpmパッケージは同じGoバイナリをラップしています。すべてのCLIコマンドは同じように動作します。lint などのコマンドにはまずスキーマスナップショットが必要です — クイックスタート を参照してください。プレビルドバイナリはmacOS（Apple Silicon + Intel）、Linux（x64 + arm64）、Windows x64をカバーしています。他のプラットフォーム（Alpine/musl、Windows arm64）では、Homebrewを使用するか、ソースからビルドしてください。
ソースからビルド：
Go 1.26以降が必要です。まだインストールしていない場合は、go.dev/dl からインストールしてください。
git clone https://github.com/boringsql/dryrun.git
cd dryrun
go build -o bin/dryrun ./cmd/dryrunバイナリは bin/dryrun にあります。
dryrun をインストールしたら、このリポジトリのクローンから、既製のスキーマスナップショットをlintできます。データベースは不要で設定も不要です：
git clone https://github.com/boringsql/dryrun.git
cd dryrun/examples/demo
dryrun lint（npmまたはHomebrewでインストールしたが、リポジトリをクローンしていない場合は、examples/demo はありません — クイックスタート にジャンプして、dryrun を自分のスキーマに向けてください。サンプル出力は、は lint が生成するものです。）
[ERROR] public.audit_log: table has no primary key
fix: add a primary key (bigint GENERATED ALWAYS AS IDENTITY recommended)
[WARN ] public.audit_log: gap in range partitions: ends at '2024-07-01' but next starts at '2024-10-01'
fix: inserts into the gap will fail unless a DEFAULT partition exists
[ERROR] public.task_comments: table has no primary key
fix: add a primary key (bigint GENERATED ALWAYS AS IDENTITY recommended)
[WARN ] public.projects.created_at: timestamp column uses timestamp without time zone instead of timestamptz
fix: use timestamptz for timestamp columns
[ERROR] public.tasks.project_id: FK 'tasks_project_id_fkey' on column(s) (project_id) has no covering index
fix: add an index on FK columns to avoid sequential scans on DELETE/UPDATE
[WARN ] public.users.email: column 'email' uses character varying(255), prefer text
fix: VARCHAR(n) adds a hidden CHECK constraint with no performance benefit
[WARN ] public.user_notifications: table is missing 'created_at' column
fix: add: created_at timestamptz NOT NULL DEFAULT now()
26 finding(s): 6 error, 20 warning, 0 info (13 tables checked)データベースは必要ありません。オフラインのスナップショットから完全に動作します。
同じデモはMCPでも動作します。examples/demo から、サーバーをYou're your assistantに登録します：
claude mcp add dryrun -- npx -y @boringsql/dryrun mcp-serveそのディレクトリから、質問してください：「私が持っているテーブルは何ですか、そしてそれらの何が問題ですか？」
1つのコマンドでサーバーをAIエージェントに組み込めます。setup はClaude Code、Cursor、Codex、Zedを検出し、エージェントのMCP構成を書き込み、SQLを書く前にエージェントがスキーマを確認するように AGENTS.md/CLAUDE.md に指示を追加します：
dryrun setup自分でエージェントを選ぶか、非対話シェルから実行する場合は、--agents セットを渡します：
dryrun setup --agents=claude,cursor # or: allサーバーを手動で登録するには：
# for claude code
claude mcp add dryrun -- dryrun mcp-serve
# for codex
codex mcp add dryrun -- dryrun mcp-serveソースからビルドした場合は、バイナリの完全なパスを使用してください：
claude mcp add dryrun -- /path/to/dryrun mcp-serveまたは、インストールが不要でクライアントが npx を指すようにします：
claude mcp add dryrun -- npx -y @boringsql/dryrun mcp-serveこの形式の生のクライアント設定：
{
"mcpServers": {
"dryrun": {
"command": "npx",
"args": ["-y", "@boringsql/dryrun", "mcp-serve"]
}
}
}サーバーは、現在のプロジェクトの .dryrun/history.db から最新のスナップショットを読み取ります。データベース資格情報は不要です。アシスタントはオフラインのスナップショットから完全なスキーマインテリジェンスを取得できます。
スナップショットがなくてもサーバーが開始され、そのツールはスキーマが読み込まれていないと答えます。dryrun init --db "$DATABASE_URL" でキャプチャするか、チームメイトがプッシュしたスナップショット（dryrun snapshot pull --from-path ./snapshots — クイックスタクスター）を取得して、アシスタントから reload_schema ツールを呼び出してください。新しいスキーマはサーバーを再起動せずに認識されます。
複数のデータベースが存在するプロジェクトでは、データベースごとに1つの dryrun mcp-serve を実行し、クライアント構成にサーバーごとのエントリを追加します。単一のMCPプロセス内での本格的な複数データベースの提供は、#7 で管理されています。
ライブデータベースのセットアップ、SSEトランスポート、Claude Desktopの設定については、チュートリアルを参照してください。
始め方には2つの方法があります。あなたの環境に合ったものを選んでください。
PostgreSQLインスタンス（ローカル、開発、本番）に接続できる場合、1つのコマンドですべてを実行できます：
dryrun init --db "$DATABASE_URL"これは dryrun.toml（ [project] id とデフォルトのプロファイル）と .dryrun/ データディレクトリを作成し、データベースを .dryrun/history.db にキャプチャします。スナップショットは (project_id, database_id) でキーキーされます。プロジェクトに複数のデータベースがある場合は（例： auth、billing）、プロファイルごとに database_id を設定します。完全な構成リファレンスは docs/dryrun-toml.md を参照してください。
資格情報を持つ人が一度だけキャプチャし、共有ディレクトリ（リポジトリ内、または両側が到達できる場所）にプッシュします：
dryrun init --db "$DATABASE_URL"
dryrun snapshot push --to-path ./snapshots彼らは dryrun.toml と ./snapshots の両方をコミットします。他の全員がプルします：
dryrun snapshot pull --from-path ./snapshotssnapshot pull はスナップショットを .dryrun/history.db にロードします。彼らのマシンではデータベースは不要です。
dryrun.toml のコミットは任意ではありません：スナップショットは (project_id, database_id) でキーされ、 dryrun init は database_id をライブデータベース名から焼き込みます。--db なしで dryrun init を実行したチームメイトは異なる database_id を取得するため、 pull はソースが持たないキーの検索になるので 0 copied と報告します。
プッシュされたスナップショットは、スキーマと共にプランナーとアクティビティ統計を含みます。したがって、サイジングとvacuumデータを必要とするオフラインツールも動作します — それはプレーンなJSONエクスポートにはできないことです。ディレクトリの代わりにレジストリを使うには、dryrun remote add と snapshot push --remote を参照してください。人間やエージェントが読めるJSONを渡す場合は、 dryrun dump-schema も同様に書き出します。それはエクスポートであり、入力ではありません。
dryrun lintすべてのコマンドは .dryrun/history.db からオフラインで動作します。各プロジェクトには独自の dryrun.toml と .dryrun/があり、グローバルな状態はありません。.dryrun/ を .gitignore に追加します。
スナップショットは .dryrun/history.db に入り、(project_id, database_id) でキー付けされます。これが唯一のスキーマソースです：MCPサーバー、lint、drift はすべてこれれから読み取ります。以前のdryrunから残った .dryrun/schema.json は無視されます。
snapshot take はプライマリに対して実行され、スキーマとプランナー統計を書き込みます。アクティビティカウンター（idx_scan、n_dead_tup、最終vacuum）は各レプリカにあるため、それらを別々にキャプチャしてください：
dryrun --profile primary snapshot take
dryrun --profile replica1 snapshot activity --from "$REPLICA1_URL" --label replica1
dryrun --profile replica2 snapshot activity --from "$REPLICA2_URL" --label replica2MCP の describe_table（ノード別内訳）と detect kind=anomalies ツールは、ノード別の idx_scan を公開し、ルーティングの不均衡を特定できます。docs/multi-node-stats.md を参照してください。
dryrun snapshot take は、スナップショットを (project_id, database_id) でキー付けします。デフォルトで動作します — project_id はフォルダー名、database_id は current_database() からの実際のデータベース名です：
dryrun init --db "$AUTH_DB" # captures auth
dryrun snapshot take --db "$BILLING_DB" # captures billing into its own stream
dryrun snapshot list --db "$AUTH_DB" # only auth snapshots安定した参照用（および list / diff でURLの再入力なしに実行できるように）に、dryrun.toml でプロファイルを宣言します：
[project]
id = "myapp"
[profiles.auth]
db_url = "${AUTH_DATABASE_URL}"
database_id = "auth"
[profiles.billing]
db_url = "${BILLING_DATABASE_URL}"
database_id = "billing"次に：
dryrun --profile billing snapshot list
dryrun --profile billing snapshot diff --latestすべてのプロファイルオプションは docs/dryrun-toml.md を参照してください。
DB関連のすべてのコマンド (init、 probe、 dump-schema、drift、stats apply、snapshot のすべてのサブコマンド) は --profile を受け入れ、--db が指定されていない場合は解決されたプロファイルの db_url にフォールバックします。lint はオフラインです。.dryrun/history.db を読み取り、--db を明示的に渡した場合にのみライブデータベースに触れます。
注意： MCP サーバーは現在単一データベースです。デフォルトのプロファイルを使用してください。または、データベースごとに1つの
dryrun mcp-serveプロセスを実行するオプションがあります。1つのMCPプロセス内のネイティブな複数データベースのサポートは、#7 で管理されています。
DryRun の価値はチーム構成で高まります。複数の開発者が任意のPOSIX準拠ディレクトリからスナップショットをプルできます。
スナップショットを公開するには、次が必要です：
cd project_name
# capture from the live DB (use cwd name for project name)
dryrun init --db "$DATABASE_URL"
dryrun snapshot take --db "$DATABASE_URL"
dryrun snapshot push --to-path ./snapshots --all開発者は次にスナップショットをローカルの履歴にインポートできます：
dryrun snapshot pull --from-path ./shared/snapshots --allスナップショットはコンテンツアドレス可能（{project}/{database}/{ts}-{hash}.json.zst）であり、冪等です。同じスナップショットを2回プッシュしても変更はありません。
最も簡単な展開は、専用のgitリポジトリです。スナップショットのリポジトリを作成し、*.json.zst binary を .gitattributes に追加して、gitがバンドルの差分を試みないようにします。
オフラインツール（lint、check_migration、drift）はプル後にすぐに機能します。
サーバーなし、資格情報なし。以前と同じ約束です。
あらゆるOCIレジストリがスナップショットを保持できます。GitHub Container Registry、Google Artifact Registry、Amazon ECR、Docker Hub、Harbor、またはセルフホストのものも利用できます。レジストリが認証、保持、アクセス制御を処理するため、稼働させるサーバーは不要です。
docker pushと同じ要領で認証し、リモートを登録してプッシュします：
docker login ghcr.io
dryrun remote add ghcr --ref ghcr.io/myorg/dryrun --default
dryrun snapshot take --pushsnapshot take --pushは、スナップショットの取得と公開を一度に行います。取得側はプルします：
dryrun snapshot pull --remote ghcrpullはデフォルトで最新の取得結果だけを取得します。そのため、コールドプル（新しいCI環境、空のhistory.db）でも、レジストリにどれだけ履歴が保持されていても低コストです。--fullで履歴全体をバックフィルするか、--since 7d（2w、24h、2026-01-01のようなUTC日付にも対応）で期間を指定できます。pushは常にローカルの完全な履歴を送信します。コンテンツ・ハッシュの増分で管理されるため、定期期にプッシュしている運用者は、実行するたびに新た観測だけをアップロードします。
--refはレジストリのベースを指定します。各データベースは、その配下に<ref>/<project_id>/<database_id>という専用リポジトリを持ちます。したがえば、myappのauthデータベースはghcr.io/myorg/dryrun/myapp/authに配置されます。スナップショットは、コンテンツ・ハッシュでアードレスされるOCイアーティファクトに対応付けられるため、同じものを2回プッシュしても何も変わらず、共有されたブ・ロブはレジスト上で重複排除されます。Google Artifact Registryの場合、docker loginの代わりに Cloud auth config ure-docker us-docker.pkg.devを実行します。それ以外は同じです。
認証。 デフォルトでは、dryrunがDockerの資格情報（~/.docker/config.jsonとクレデンシャルヘルパー）を再利用で、docker loginが使えるレジストリまでは追加設定なしで動きます。remote addの2つのオーバーライドで、残りも運ます：
--token-env VARは、環境変数から静的なベアラート開を読み取ます。短命トークンを発行するレジストリ向けです（例：gcloud auth print-access-tokenから供給 --token-env GAR_TOKEN）。
--auth gcpは、Google Application Default Credentialsを直接利用します。すれば、Google Artifact Registry / Container Registryは、gcloud auth login（またはGOOGLE_APPLICATION_CREDENTIALSによるサービスアカウントキー）の後で、configure-dockerを実行しなくても動きます。ADCトークンは自動的に更新されます。
プロファイル単位のリモート設定や、プロジェクトをまたいだ1つのストリームの共用については、docs/dryrun-toml.mdを参照してください。
チュートル オフライン、オンライン、マルチノードのワークフロウと完全なツール・リファレンス
マルチノード統計 クラスタ全体会の統計収集、集約ルール、レプルカの不均衡を検出
クエリ統計 pg_stat_statementsのキャロ、形グループ化、差フフング
設定リファレンス dryrun.tomlのプロファイル、規約、リモート、リン トルール
CLLIの安定性 安定したコマンドと実験的コマンドの区分
セキュリテイ概要 CLI/MCP分離レとマスキン
boring ブログとプロジェクトのホーム
dryrunプロジェクト・ページ 概要とドキュメント
**本番データベースにAIを触れさせない、なぜほとんどのPostgres MCPが安全でなのか、dryrun`がどう違うのか
RegreSQL SQLリグレッションテスト、そして**dryrun**のコンパニオンツール
Fixturize 本番データをサブセト化・マスク化する開発/テスト
This server cannot be deployed
Deterministic safety, correctness & cost gate that vets Postgres SQL before your AI agent runs it.
Query PostgreSQL databases in plain English — LLM-generated, safety-validated SQL.
Query your Postgres from ChatGPT or Claude without exposing the database or handing over credentials. Run npx boltschema connect next to your database and it dials out over HTTPS — no inbound firewall rule, no open port, works with localhost and VPC-private databases. Read-only is enforced by a SQL guard, a Postgres READ ONLY transaction, and a scoped role generated for you.
Safe, read-only Postgres and MySQL access for AI agents. Audit log + column-level controls.
