データベース2026年10月8日

PostgreSQL本おすすめ｜レベル別の読む順番

PostgreSQLの本は「SQL」「内部構造」「運用・チューニング」の3層で選ぶ
独学ロードマップ：3か月でSQLから運用までを一周する読む順番
レベル別・目的別のおすすめ本と選び方
OSS-DB Silver・Goldの対策は書籍だけで足りるのか
本だけでは埋まらない部分を公式ドキュメントと検証環境で補う
よくある質問
まとめ：いま困っているレイヤから1冊目を決める

このテーマのまとめPostgreSQLが遅い・詰まる原因｜VACUUMと実行計画、ロック

本記事にはプロモーション（広告）が含まれています。

PostgreSQLの本を探すと、SQL入門書からアーキテクチャ解説、試験対策本までが同じ検索結果に並びます。しかし「テーブル設計を任された」「VACUUMが追いつかずテーブルが肥大化した」「実行計画が読めない」は、それぞれ別のレイヤの問題です。1冊目を間違えると、読み終えても目の前の障害を切り分けられません。

ここではPostgreSQL関連書籍を「SQL」「内部構造」「運用・チューニング」の3層に分け、対象レイヤ・前提知識・対応バージョン・ハンズオン量の4軸で選び方を整理します。あわせて3か月で一周する読む順番、OSS-DB Silver対策との使い分け、公式ドキュメントと検証環境での補い方まで扱います。

PostgreSQLの本は「SQL」「内部構造」「運用・チューニング」の3層で選ぶ

PostgreSQLの書籍はおおよそ3層に分かれます。層が違う本を比べて優劣を論じても、答えは出ません。

第1層はSQLとリレーショナルモデルです。SELECT・JOIN・集約から、サブクエリ、ウィンドウ関数、CTE、正規化とテーブル設計までを扱います。この層の知識はPostgreSQL固有ではなく、MySQLやOracleでもほぼそのまま通用します。つまりPostgreSQL専用の本である必要はありません。

第2層は内部構造とアーキテクチャ。MVCC（タプルのxmin/xmax、可視性判定）、WALとチェックポイント、VACUUMとFREEZE、共有バッファとOSページキャッシュ、プランナの推定ロジック、ロックの種類と競合。ここはエンジン固有の知識です。「なぜUPDATEしただけでテーブルが太るのか」「なぜインデックスがあるのにSeq Scanが選ばれるのか」に答えられるのは、この層だけです。

第3層が運用・チューニング・トラブルシュートです。postgresql.confのパラメータ設計、バックアップとPITR、レプリケーション、監視項目、スロークエリの特定、障害時の切り分け手順。第2層の理解がないと、この層の本は設定値の暗記リストにしか見えません。

実務でつまずく人の多くは、第1層だけを固めた状態で第3層の作業を任されています。第2層が抜けているのでパラメータを変えても効果を説明できず、VACUUM周りのトラブルで手が止まります。

比較の軸は対象レイヤ・前提知識・対応バージョン・ハンズオン量

書店やECサイトの説明文からは、次の4点を読み取ってください。

軸	確認方法	判断基準
対象レイヤ	目次で「JOIN」「ウィンドウ関数」が主ならSQL層、「MVCC」「WAL」「VACUUM」が章になっていれば内部構造層、「パラメータ」「バックアップ」「監視」が並べば運用層	自分が今困っている層と一致しているか
前提知識	「前提」「対象読者」の記述。`psql`の操作説明があるかどうか	説明がない前提は自力で埋める覚悟が必要
対応バージョン	タイトルや奥付の対応バージョン、発行年	後述の「使える/使えない」基準で判断
ハンズオン量	サンプルDBの提供有無、コマンド実行例の密度、環境構築の章の有無	手を動かす前提なら実行例が多いものを選ぶ

一番誤解されやすいのが対応バージョンの扱いです。SQL構文とリレーショナルモデルの本は、10年前の版でも大半が通用します。一方で次の領域は、バージョン差が実務に直結します。

VACUUM/autovacuumではautovacuum_vacuum_insert_threshold（PostgreSQL 13で追加）のように、INSERT中心のテーブルでもautovacuumが走る条件が増えました。古い本の「追記のみのテーブルはVACUUM不要」という前提では説明が足りません。インデックスはB-treeの重複排除（13）とボトムアップ削除（14）で肥大化の挙動が改善され、REINDEX前提の運用設計は見直しが必要です。バックアップはpg_basebackupの増分バックアップとpg_combinebackup（17）により、取得方式の選択肢そのものが増えました。監視・統計ビューではpg_stat_io（16）やEXPLAIN (WAL)（13）が切り分けに使えます。SQL構文ではMERGE（15）などが追加されています。

したがって第1層の本は版が古くても投資効率が高く、第2層・第3層はできるだけ新しい版を選ぶのが基本方針になります。ただしMVCCやWALの原理そのものは変わらないため、第2層は「少し古いが評価の高い本」を読み、差分をリリースノートと公式ドキュメントで埋める戦略も現実的です。

この記事のテーマをさらに学べる本

実行計画を読み解きながら条件分岐・集約・結合の書き方を学べ、SQL層の学習に使えます。

［改訂新版］SQL実践入門──高速でわかりやすいクエリの書き方ミック

楽天ブックスで詳しく見る Yahoo!ショッピングで見る

独学ロードマップ：3か月でSQLから運用までを一周する読む順番

週に5〜8時間を確保できる前提の12週プランです。各ステップの到達チェックは、読了ではなく自分の言葉で説明できるかで判定します。

Step1（1〜4週目）SQLとリレーショナルモデルの土台を作る

最初の4週はPostgreSQL固有の話を脇に置き、SQLに集中します。ここを飛ばすと、実行計画を読む段階で「そもそもこのクエリは何をしたいのか」が整理できず詰まります。

やることは3つです。

SELECT〜JOIN〜集約を手で書く。GROUP BYとHAVINGの違い、INNER/LEFT JOINの行数変化、NULLが絡む比較とCOUNT(列)の挙動を、実際に実行して確認します。
サブクエリ・CTE・ウィンドウ関数まで届かせる。ROW_NUMBER()で重複排除、SUM() OVER (PARTITION BY ... ORDER BY ...)で累計、LAG/LEADで前後行比較の3パターンが書ければ、十分なスタートです。
正規化と主キー・外部キー・制約の設計。第3正規形までの手順と、意図的に崩す場合の判断基準（更新頻度、参照整合性の担保先）を言語化します。

到達チェックは次の3点です。

LEFT JOINした結果にWHEREで右表の条件を書くと内部結合相当になる理由を説明できる
NULLを含む列に対するNOT INが期待通りに動かない理由を説明できる
「このテーブルに一意制約を張るべきか」を、業務ルールから説明できる

この層の書籍は選択肢が多く、ミック氏の『SQL ゼロからはじめるデータベース操作』『達人に学ぶSQL徹底指南書』『SQL実践入門』、設計寄りなら『達人に学ぶDB設計徹底指南書』、落とし穴の網羅なら『SQLアンチパターン』が定番です。1冊目は入門、2冊目に実践寄りという構成が素直でしょう。版が複数出ているものは、最新版の対応内容を確認してください。

Step2（5〜8週目）MVCC・WAL・VACUUMで「なぜそうなるのか」を理解する

ここがPostgreSQL固有の核心で、独学で最も飛ばされやすい層です。

PostgreSQLのMVCC（多版型同時実行制御）は、UPDATEを「旧行に削除マークを付け、新しい行を追記する」方式で実現します。各行にはトランザクションIDがxmin（挿入したトランザクション）とxmax（削除したトランザクション）として記録され、スナップショットと突き合わせて可視性が判定されます。帰結は3つです。

UPDATEのたびに不要行（デッドタプル）が増え、テーブルファイルは自動では縮まない
読み取りは書き込みをブロックしない（READ COMMITTEDでの一貫性の範囲は要確認）
長時間トランザクションや古いレプリケーションスロットがあると、不要行を回収できない

Oracle経験者が混乱しやすい箇所でもあります。OracleはUNDO表領域に旧イメージを置きますが、PostgreSQLはテーブル本体に旧行を残すため、症状は「UNDO不足」よりも「テーブル肥大化」として現れます。この違いはOracle から PostgreSQL 移行でハマるポイントで扱っている空文字とNULLの違いと並んで、移行時に押さえておきたい知識です。

VACUUMはデッドタプルを回収して再利用可能にする処理、FREEZEはトランザクションIDの周回（wraparound）を防ぐために古い行を「常に可視」としてマークする処理です。目的の違いを区別できていないと、autovacuum_freeze_max_age絡みの強制autovacuumや、VACUUM FULL（排他ロックを取り、ファイルを作り直す）と通常VACUUMの違いを判断できません。

WALの理解も同様に効いてきます。更新はまずWALに書かれ、共有バッファ上のページは後からチェックポイントでディスクに反映されます。ここを押さえると、クラッシュリカバリが「最後のチェックポイント以降のWALを再適用する」処理であること、checkpoint_timeoutやmax_wal_sizeの変更でI/Oのピークと復旧時間がトレードオフになること、full_page_writesが部分書き込み対策として必要なこと、PITRがベースバックアップとWALアーカイブで成立することが、一つの線でつながります。レプリケーションスロットがWALを保持してディスクを圧迫する問題も同じ仕組みの話で、詳細はPostgreSQL論理レプリケーションのWAL保持とスロット運用のrestart_lsnの読み方が参考になります。

到達チェックは次の3点です。

pg_stat_user_tablesのn_dead_tupとlast_autovacuumを見て、肥大化しているテーブルを特定できる
「HOT update」が効く条件（更新列がインデックスに含まれない、ページ内に空きがある）を説明できる
VACUUM FULLを本番で避ける理由と代替手段を挙げられる

この層の定番は『内部構造から学ぶPostgreSQL 設計・運用計画の鉄則』です。改訂版が出ているので、購入時に対応バージョンを確認してください。無料で読める資料では鈴木啓修氏の「The Internals of PostgreSQL」が、バッファマネージャやプランナの内部を図で追える点で書籍と相性が良いです。

この記事のテーマをさらに学べる本

PostgreSQLの内部構造と照らし合わせて設計・運用計画を解説しており、内部構造層に対応します。

［改訂3版］内部構造から学ぶPostgreSQL-設計・運用計画の鉄則上原一樹/勝俣智成/佐伯昌樹/原田登志

楽天ブックスで詳しく見る Yahoo!ショッピングで見る

Step3（9〜12週目）実行計画の読み方とバックアップ・リカバリ運用に進む

最後の4週で、第2層の知識を運用の判断に変換します。

EXPLAINだけでは推定値しか見えません。実測と比較するにはEXPLAIN (ANALYZE, BUFFERS)を使います。

EXPLAIN (ANALYZE, BUFFERS, VERBOSE)
SELECT o.id, c.name
  FROM orders o
  JOIN customers c ON c.id = o.customer_id
 WHERE o.created_at >= now() - interval '7 days';

読む順番は内側（インデントが深いノード）から外側へ。チェックするのは次の点です。

rows=の推定値とactual rows=の実測値の乖離。10倍以上ずれていれば統計情報（ANALYZE）やデータ分布、相関のある複数列条件を疑う
Buffers: shared hit=... read=...。readが多ければキャッシュに乗っていないI/O
Sort Method: external merge Disk: ...kB が出ていればwork_mem不足でディスクソート
結合方式（Nested Loop / Hash Join / Merge Join）が、行数見積もりに対して妥当か
Filterで大量に捨てていないか（Rows Removed by Filter）

統計情報が壊れている、あるいは存在しないケースは意外と多く、スナップショットから復元した環境では特に注意が必要です。この挙動はAurora PostgreSQLスナップショット復元と統計情報で整理されています。

スロークエリは、個別クエリを見る前に全体から当たりを付けます。pg_stat_statementsを有効化し、total_exec_timeの降順で上位を見るのが定石です。1回が遅いクエリより、速いが呼ばれすぎているクエリのほうが総時間を食っていることがよくあります。

遅いのではなく詰まっている場合は、pg_stat_activityのwait_event_type/wait_eventとpg_locksを見ます。Lock待ちならどのトランザクションが先頭でブロックしているのかを追い、LWLockやIOなら別の方向の調査になります。症状別の手順を持っておくと早いので、PostgreSQL 運用・トラブル解決ガイドのような切り分けフローと書籍を併用してください。

バックアップは、pg_dump（論理）とpg_basebackup（物理）の違い、WALアーカイブを使ったPITRの手順を、実際に「落として戻す」まで一度やります。手順書を読むだけでは、recovery_target_timeを指定したときにどこまで戻るのか、restore_commandが失敗したときに何が起きるのかが身につきません。

到達チェックは次の3点です。

「夜間バッチが遅い」という報告から、調査する統計ビューの順番を自分で決められる
RPO/RTOの要件から、論理バックアップと物理バックアップ＋PITRのどちらを選ぶか説明できる
検証環境でPITRを完走させ、復旧完了の判断条件（pg_is_in_recovery()、ログのリカバリ完了メッセージ）を示せる

レベル別・目的別のおすすめ本と選び方

ここからは層ごとに、何を基準に選ぶかを具体化します。書名は定番として広く挙げられるものを例示しますが、版と対応バージョンは現物で確認してください。

SQL入門〜中級：テーブル設計とウィンドウ関数まで届く本

選ぶ基準は4つあります。

ウィンドウ関数が独立した章になっているか。入門書には集約関数で終わるものもあります。実務のレポートや重複排除でウィンドウ関数は必須なので、ここが分水嶺です。
実行計画に一言でも触れているか。「このSQLはこう書き換えたほうが速い」という記述に、インデックスや結合方式という理由が添えられているかで、第2層への橋渡しになるかが変わります。
サンプルDBがPostgreSQLで動くか。SQL Server/Oracle前提の構文（TOP、DECODE、NVL、ROWNUMなど）が多い本は、読み替えのコストがかかります。
設計の本を別途1冊入れるか。SQLが書けても、正規化と制約の判断は別スキルです。設計を扱う本（『達人に学ぶDB設計徹底指南書』など）か、失敗パターンから学ぶ本（『SQLアンチパターン』『失敗から学ぶRDBの正しい歩き方』など）を併読すると、レビューで指摘できる観点が増えます。

SELECT〜JOINは書けるが3テーブル以上の結合や「グループごとの最新1件」を毎回調べている人、ER図を見て主キーの妥当性を言えない人は、この層から始めてください。

内部構造・アーキテクチャ：MVCC、WAL、プランナを扱う本

目次と検証コマンドを見れば、ある程度判断できます。

目次に「MVCC」「WAL」「VACUUM」「バッファ」「プランナ」が揃っているか。どれかが欠けていると、トラブル時の説明が片側しかできません。
行の内部表現に踏み込んでいるか。xmin/xmax/ctid、ページ構造（ヘッダ、ラインポインタ、タプル）、FSM/VMといった用語が出てくる本は、肥大化やインデックスオンリースキャンの話まで接続できます。
プランナのコスト計算を扱っているか。seq_page_cost/random_page_cost/cpu_tuple_costといったパラメータと、選択率推定（pg_statsのヒストグラム、n_distinct、MCV）の説明があるかを見ます。ここを扱わない本は、実行計画の章があっても読み方までで止まります。
検証コマンドが載っているか。pageinspectやpg_freespacemapといった拡張で内部を覗く記述があれば、読んだ内容をその場で確認できます。

内部構造は読むだけでは定着しません。MVCCの章を読んだら、次のように自分で可視性を観察します。

CREATE TABLE t (id int primary key, v text);
INSERT INTO t VALUES (1, 'a');

SELECT ctid, xmin, xmax, * FROM t;

UPDATE t SET v = 'b' WHERE id = 1;

-- 更新後、新しいタプルの位置（ctid）が変わっていることを確認
SELECT ctid, xmin, xmax, * FROM t;

-- デッドタプルの状況
SELECT relname, n_live_tup, n_dead_tup, last_autovacuum
  FROM pg_stat_user_tables WHERE relname = 't';

VACUUMの設定をデフォルトのままにしている人、インデックスを追加したが速くならなかった理由を説明できない人、レプリケーション遅延やWAL溜まりの原因調査で手が止まる人は、この層からです。

運用・トラブルシュート：性能問題とアンチパターンに強い本

実務で強いのは、症状起点で構成された本です。「遅い」「詰まる」「肥大化する」「接続できない」という入口から、見るべきビューとコマンドにたどり着ける構成かを確認してください。パラメータのリファレンス的な並びは、公式ドキュメントで代替できます。

残りの3点も目次で見分けられます。監視項目は数値そのものより、「なぜその指標を見るのか」「環境によってどう変わるか」が書かれているか。バックアップ/リカバリはPITRの章がコマンド付きで、復旧の確認方法まで書かれているか。そしてクラウドとの差分です。マネージドサービスではスーパーユーザー権限や一部パラメータが制限され、Auroraはストレージ層が独立しているためWALやチェックポイントの挙動も異なります。オンプレ前提の本だけでは、レプリカラグの意味やServerless v2でのパラメータ適用タイミングといったAurora特有の挙動は埋まりません。

本番の障害対応当番に入っている人、性能劣化の問い合わせでどのビューから見るかの順番が決まっていない人は、この層からです。

この記事のテーマをさらに学べる本

内部構造からレプリケーション・バックアップ・モニタリングまで扱い、運用層の体系化に向きます。

PostgreSQL実践入門──アーキテクチャ、運用監視、性能改善堀口恭太郎/細谷柚子/渡佑也/山田達朗/白石裕輝/須賀啓敏

楽天ブックスで詳しく見る Yahoo!ショッピングで見る

OSS-DB Silver・Goldの対策は書籍だけで足りるのか

OSS-DB技術者認定試験（LPI-Japan）は、PostgreSQLを題材にした国内の認定試験です。Silverは運用管理の基礎、GoldはSQLチューニングや障害対応といった上位領域を扱います。

Silverは、市販の対策本と問題集、手を動かす環境で到達できる範囲です。ただし試験のバージョン（Ver.2.0 / Ver.3.0など）と対応するPostgreSQLバージョン、出題範囲は改訂されます。申し込み前に公式サイトの最新の出題範囲を確認してください。古い版の対策本を使う場合は、出題範囲との差分を自分で埋める必要があります。

書籍だけで不足しがちなのは3点です。コマンドのオプションを問う設問は、pg_dumpの-F、psqlのメタコマンド（\d、\dt+、\du、\l）、pg_ctlのモード指定など、実際に打っていないと選択肢を絞れません。設定ファイルの記述ルールも同様で、postgresql.confとpg_hba.confの認証方式（scram-sha-256、md5、peer、trust）、pg_hba.confの行の評価順（上から最初にマッチした行が適用される）は、書き換えて接続を試すのが最短です。権限とロールではGRANT/REVOKEの対象と、CREATEROLEやLOGIN属性の違いを押さえます。

無料教材では、LPI-Japanが公開している「オープンソースデータベース標準教科書」がSilverの入口として使えます。学習の進め方の詳細はOSS-DB Silver 独学の勉強法｜教材選びと学習ロードマップにまとめがあります。

試験対策本と技術書のどちらを先に読むべきか

目的によって順番が変わります。

転職や社内の資格要件で数か月以内に合格が必要なら、対策本と問題集を先に回します。出題範囲が明示されているため、範囲内を埋めるほうが効率的です。ただし問題集の暗記だけで通すと、合格後に実務で使えない状態になりがちです。対策本に出てきたキーワード（MVCC、WAL、VACUUM、チェックポイント）はその場で検証環境で触り、後から第2層の技術書で回収する前提にしてください。

期限がなく実務で使えるようになるのが主目的なら、技術書が先です。内部構造を理解したうえで対策本を読むと、設問が知識の確認として素直に解けます。この順番はGold以降や実際の障害対応にも役立ちます。

迷う場合の目安は、業務での接触頻度です。PostgreSQLを週に数回以上触っているなら技術書優先、ほとんど触っていないなら対策本優先。触っていない状態で内部構造の本を読んでも、具体的なイメージが湧かず読み進められません。

OSS-DB Silver 対策テキスト（OSS教科書）

PostgreSQLの仕組みを体系的に学ぶなら、OSS-DB Silverの公式対応テキストが近道です。資格を取らなくても基礎固めに役立ちます。

OSS教科書 OSS-DB Silver Ver.3.0対応（EXAMPRESS） [ 福岡博 ]

本だけでは埋まらない部分を公式ドキュメントと検証環境で補う

書籍は体系立てて読める反面、どうしても執筆時点のバージョンで固定されます。そこを埋めるのが公式ドキュメントとリリースノートです。

公式ドキュメントは通読せず、逆引きで使います。パラメータの正確な意味とデフォルト値、適用に再起動が必要か（context）は「サーバ設定」。VACUUM、ANALYZE、インデックス再構築、ログ管理は「ルーチンデータベース保守作業」。pg_dump/pg_basebackup/PITRは「バックアップとリストア」。統計ビューの各列の定義は「監視」。EXPLAINとプランナのコスト定数、統計情報は「性能に関するヒント」を見ます。

日本語版（PostgreSQL日本語ドキュメント）は便利ですが、最新版への追随に差が出る場合があります。パラメータの詳細や新機能は、英語版と突き合わせるのが確実です。

リリースノートは、本の対応バージョンから現在使っているバージョンまでの範囲で、「Migration to Version X」のセクションと、VACUUM・インデックス・レプリケーション関連の変更に絞って目を通せば足ります。全部読む必要はありません。

Dockerで作る検証環境と、本と並行して回す確認コマンド

検証環境はDockerが最短です。バージョンを変えて挙動を比較できるので、「この本の記述が今のバージョンでも成り立つか」をその場で確認できます。

# docker-compose.yml
services:
  pg17:
    image: postgres:17
    environment:
      POSTGRES_PASSWORD: postgres
      POSTGRES_INITDB_ARGS: "--encoding=UTF8 --no-locale"
    ports: ["55432:5432"]
    command: >
      postgres
      -c shared_preload_libraries=pg_stat_statements
      -c logging_collector=on
      -c log_min_duration_statement=200
      -c log_lock_waits=on
      -c log_autovacuum_min_duration=0
  pg13:
    image: postgres:13
    environment:
      POSTGRES_PASSWORD: postgres
    ports: ["55433:5432"]

docker compose up -d
psql -h localhost -p 55432 -U postgres

接続したら、まず拡張を有効化しておきます。

CREATE EXTENSION IF NOT EXISTS pg_stat_statements;
CREATE EXTENSION IF NOT EXISTS pageinspect;  -- 内部構造の確認用

本を読みながら手元で回す確認コマンドを、用途別に挙げます。

-- 1. 設定値の実際の適用状況と、変更に再起動が要るか
SELECT name, setting, unit, context, source
  FROM pg_settings
 WHERE name IN ('shared_buffers','work_mem','max_wal_size',
                'checkpoint_timeout','autovacuum_vacuum_scale_factor');

-- 2. 肥大化とVACUUMの状況
SELECT relname, n_live_tup, n_dead_tup,
       last_vacuum, last_autovacuum, last_analyze
  FROM pg_stat_user_tables
 ORDER BY n_dead_tup DESC LIMIT 20;

-- 3. テーブル/インデックスのサイズ
SELECT relname, pg_size_pretty(pg_total_relation_size(relid)) AS total,
       pg_size_pretty(pg_relation_size(relid)) AS heap
  FROM pg_catalog.pg_statio_user_tables
 ORDER BY pg_total_relation_size(relid) DESC LIMIT 20;

-- 4. 総実行時間の重いクエリ
SELECT calls, round(total_exec_time::numeric, 1) AS total_ms,
       round(mean_exec_time::numeric, 2) AS mean_ms, query
  FROM pg_stat_statements
 ORDER BY total_exec_time DESC LIMIT 10;

-- 5. 待機の状況
SELECT pid, state, wait_event_type, wait_event,
       now() - xact_start AS xact_age, left(query, 80) AS query
  FROM pg_stat_activity
 WHERE state <> 'idle' ORDER BY xact_start;

-- 6. ロック競合の先頭を特定
SELECT pid, pg_blocking_pids(pid) AS blocked_by, left(query, 80)
  FROM pg_stat_activity
 WHERE cardinality(pg_blocking_pids(pid)) > 0;

効果的なのは、章を読み終えるごとに、その章の主張が成り立たない条件を作って確かめることです。VACUUMの章なら、autovacuum = offにした状態で大量UPDATEを繰り返し、n_dead_tupとテーブルサイズが増え続けることを確認してから、手動VACUUMとVACUUM FULLでサイズの戻り方を比較します。work_memの章なら、SET work_mem = '64kB'にしてソートを含むクエリのEXPLAIN (ANALYZE, BUFFERS)を取り、external merge Diskが出ることを見ておきます。読んだ内容が自分の操作と結びつくと、記憶の残り方が変わります。

よくある質問

PostgreSQLの本は古いバージョン対応でも使える？

層によります。SQL構文とリレーショナルモデルの本（第1層）は、数年前の版でもほぼ問題なく使えます。追加された構文（MERGEなど）だけを後から補えば済みます。

MVCC・WAL・バッファといった第2層の原理部分も、基本設計は長期間変わっていないため骨格は通用します。ただしautovacuumのトリガ条件、インデックスの内部最適化、パラメータのデフォルト値は変わっているので、書かれている数値や設定推奨はpg_settingsと公式ドキュメントで現行バージョンの値を確認してください。

第3層の運用・バックアップは差分が大きい領域です。特にPostgreSQL 12でrecovery.confが廃止され、リカバリ設定がpostgresql.conf（およびstandby.signal/recovery.signal）に統合された変更は、手順書レベルで影響します。11以前対応の本の復旧手順は、そのまま使えません。

判断の目安は、サポート期限内のバージョン（PostgreSQLは原則5年のサポート）に対応した本を選ぶこと。それより古いものは第1層・第2層の学習用に限定します。

MySQLしか触ったことがない場合、どの本から読めばいい？

SQLの基礎は共通なので、第1層は飛ばして構いません。第2層の内部構造から入り、差分を意識して読むのが効率的です。押さえるべき違いは次の4点です。

MVCCの実装。MySQL/InnoDBはUNDOログに旧バージョンを保持し、パージスレッドが回収します。PostgreSQLは旧行をテーブル本体に残し、VACUUMが回収します。この違いから、PostgreSQLでは「テーブルとインデックスの肥大化」という固有の運用課題が生まれます。
クラスタインデックスの有無。InnoDBは主キーでクラスタ化されますが、PostgreSQLのテーブルはヒープで、すべてのインデックスが二次インデックス相当です。インデックスオンリースキャンにはVisibility Mapが関わります。
トランザクション分離レベルの既定値。MySQL/InnoDBはREPEATABLE READ、PostgreSQLはREAD COMMITTEDです。アプリ移植時に挙動が変わる可能性があります。
レプリケーション。PostgreSQLのストリーミングレプリケーションはWALベース（物理）で、論理レプリケーションは別機構です。

Oracle経験者も同様で、REDO/UNDOとWAL/MVCCの対応関係を整理しながら読むと、既存の知識が資産になります。

入門書を飛ばして内部構造の本から読んでも大丈夫？

次の3つをすべて満たしているなら、飛ばして問題ありません。

psqlで接続し、\d系メタコマンドでテーブル定義やインデックスを確認できる
3テーブル以上のJOINと集約を含むSQLを、調べながらでも自力で書ける
トランザクション、コミット、ロールバック、分離レベルという言葉を説明できる

満たしていない場合、内部構造の本の例示SQLが読めず、学習コストが跳ね上がります。それでもSQL入門書を1冊通読する必要はありません。「JOINと集約」「トランザクション」の章だけを先に読み、残りは必要になったときに戻る進め方で十分です。

本は何冊くらい買えば業務に対応できる？

設計・運用を任される水準なら、3層から各1冊とリファレンス的な1冊、合計3〜4冊が現実的なラインです。SQL/設計で1冊（設計の弱さを自覚しているなら設計の本をもう1冊）、内部構造で1冊、運用・トラブルシュートで1冊という配分になります。

これ以上は、冊数を増やすより同じ本を2周して検証環境で再現するほうが効果が高いです。同じ層の本を何冊も買うと、内容が重複している割に、肝心の「自分の環境で確認する時間」が削られます。

その後の追加投資先は担当環境で分かれます。クラウドのマネージドDB（RDS/Aurora）を運用するならAWSのユーザーガイドとAurora固有の挙動、アプリ開発寄りならアンチパターン系やORMの発行SQL、データ基盤寄りなら並列クエリやパーティショニングという具合です。

まとめ：いま困っているレイヤから1冊目を決める

PostgreSQLの本は「SQL」「内部構造」「運用・チューニング」の3層に分かれ、層をまたいで比較しても選べません。選ぶ軸は対象レイヤ・前提知識・対応バージョン・ハンズオン量の4つです。第1層は版が古くても通用しますが、第2層・第3層は新しい版を選び、差分をリリースノートで埋めます。3か月のロードマップはSQL（1〜4週）、MVCC/WAL/VACUUM（5〜8週）、実行計画と運用（9〜12週）の順。OSS-DB Silverは、期限があるなら対策本優先、実務力が目的なら技術書優先です。

1冊目は今困っているレイヤで決まります。SQLを書くのに毎回調べているなら第1層、SQLは書けるが遅い理由や肥大化の理由を説明できないなら第2層、原理は分かるが障害対応で手順が決まらないなら第3層です。

迷ったら第2層を選んでください。MVCC・WAL・VACUUM・プランナの4つを理解しておけば、第1層のSQLの良し悪しも第3層のパラメータ設計の意味も、後から自分で判断できます。ここが空白のままだと、何冊読んでも設定値を覚えた状態から先に進みません。

PostgreSQLの本は「SQL」「内部構造」「運用・チューニング」の3層で選ぶ

比較の軸は対象レイヤ・前提知識・対応バージョン・ハンズオン量

独学ロードマップ：3か月でSQLから運用までを一周する読む順番

Step1（1〜4週目）SQLとリレーショナルモデルの土台を作る

Step2（5〜8週目）MVCC・WAL・VACUUMで「なぜそうなるのか」を理解する

Step3（9〜12週目）実行計画の読み方とバックアップ・リカバリ運用に進む

レベル別・目的別のおすすめ本と選び方

SQL入門〜中級：テーブル設計とウィンドウ関数まで届く本

内部構造・アーキテクチャ：MVCC、WAL、プランナを扱う本

運用・トラブルシュート：性能問題とアンチパターンに強い本

OSS-DB Silver・Goldの対策は書籍だけで足りるのか

試験対策本と技術書のどちらを先に読むべきか

本だけでは埋まらない部分を公式ドキュメントと検証環境で補う

Dockerで作る検証環境と、本と並行して回す確認コマンド

よくある質問

PostgreSQLの本は古いバージョン対応でも使える？

MySQLしか触ったことがない場合、どの本から読めばいい？

入門書を飛ばして内部構造の本から読んでも大丈夫？

本は何冊くらい買えば業務に対応できる？

まとめ：いま困っているレイヤから1冊目を決める

関連記事

新着記事