業務でPostgreSQLを触り始めると、最初に決めかねるのがGUIツールです。pgAdmin 4だけで回るのか、DBeaverやDataGripに費用をかける価値があるのか。判断を分ける材料は4つあります。実行計画やロックを追えるか、本番のRDS/Auroraへ安全に接続できるか、データ移行が実務の量に耐えるか、費用を経費として説明できるか。ツールの機能一覧を眺めるだけでは、この4点は埋まりません。
この記事は要約版です。7ツールの機能比較表、用途別の選び分け、踏み台とSSLを使った本番接続の設定手順は、ブログの完全版にまとめています: PostgreSQL GUIツールおすすめ7選|比較と選び方
結論:無料2本を併用してから有料版を判断する
最も失敗しにくい進め方は、無料のpgAdmin 4とDBeaver Communityを両方入れて1〜2週間使い、具体的に何が足りなかったかを言語化してから有料版を検討することです。管理と障害調査が中心ならpgAdmin 4で足ります。マルチDBやデータ移行が主務ならDBeaver Community、機能不足を感じた時点でPROを検討します。SQLを書く量が多い人はDataGrip、Windowsで設計書とER図も扱うならA5:SQL Mk-2、軽い参照用途はTablePlusやPosticoが候補になります。
ツール選びと同じくらい重要なのが、接続を作る前の準備です。どのツールを選んでも先にやることは変わりません。参照専用ロールを作る、本番接続に色を付ける、フェッチ件数を絞る、踏み台とSSLを正しく設定する。この4つを済ませてから本番のエンドポイントを登録してください。
事故が起きやすい箇所も決まっています。GUIの「実行計画」ボタンがEXPLAIN ANALYZE相当だと、UPDATEやDELETEに対して押した時点でデータが変わります。DDLダイアログをうっかりOKしてALTER TABLEが強いロックを取り、後続のSELECTまで止まることもあります。自動コミットOFFのまま放置したセッションはidle in transactionとして残り、ロックを握るだけでなく最古のトランザクションがxminを押さえてVACUUMの回収を妨げます。
最初に入れる参照専用ロール
ツール側の「読み取り専用」チェックは設定漏れやプロファイル使い回しで外れます。サーバ側の権限が最後の砦です。
-- 参照専用ロールを作る
CREATE ROLE ro_viewer LOGIN PASSWORD '***';
ALTER ROLE ro_viewer SET default_transaction_read_only = on;
GRANT CONNECT ON DATABASE appdb TO ro_viewer;
GRANT USAGE ON SCHEMA public TO ro_viewer;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO ro_viewer;
-- 今後作られるテーブルにも自動で付与
ALTER DEFAULT PRIVILEGES IN SCHEMA public
GRANT SELECT ON TABLES TO ro_viewer;
default_transaction_read_only = onを入れておくと、このロールで接続したセッションではINSERT/UPDATE/DELETE/DDLがエラーになります。調査用アカウントはこの状態を既定にしてください。
完全版で扱っている内容
- 比較の6軸として、対応DBの範囲、実行計画と統計の分析支援、接続のセキュリティ機能、データ移行とインポート/エクスポート、動作の軽さとエディタの質、ライセンスと費用のそれぞれで何を見るか
- 7ツールの比較表(対応OS、対応DB、費用、実行計画の可視化、SSHトンネル、データ移行)と、pgAdmin 4のBinary paths設定やDashboardの統計表示に必要な
pg_monitorロールといった各ツールの癖 -
EXPLAIN (ANALYZE, BUFFERS)の可視化で見るべき4箇所(推定行数と実測行数の乖離、loops、Buffersのshared read/temp written、Rows Removed by Filter)と、DMLの計画をトランザクションで囲んで取る書き方 -
pg_blocking_pidsでブロッキングの親子関係を出すSQL、wait_event_type別の切り分け、lock_timeoutとstatement_timeoutの使い方 - 踏み台経由のSSHポートフォワードとSSM Session Managerのコマンド、トンネル経由で
sslmode=verify-fullが失敗する理由、require/verify-ca/verify-fullの選び分けとJDBC URLの書き方、RDS/Auroraで確認するセキュリティグループやrds.force_sslなど4点