Skip to content

Back matter · 20 min read

Bibliography

Every source the book cites, grouped by kind, with the chapters that cite it.

Every source the chapters cite, in their Further reading or in their text, is listed here once, so you can find the original behind any claim without hunting. Start with the manual. Read the source notes and papers when you want the why behind a mechanism. Treat vendor pages as snapshots.

Each entry gives the title, the author or publisher, the year where one applies, and the chapters that cite it. A chapter's Further reading says what a source is good for; this page says where it's cited. Living documentation has no year, so the chapters say when they checked each vendor fact.

Chapters are cited by short name: preface (Before you start); basics (Know the nouns first); latency (Where the time goes); storage (Everything is a page); buffers (The buffer cache decides what stays); MVCC (Updates are inserts); HOT (Keep your updates HOT); WAL (Write it down first); ACID (ACID, honestly); vacuum (Vacuum is not optional); not MySQL (Postgres is not MySQL); types (Types are a contract); keys (Pick your keys once); relationships (Constraints, chosen on purpose); models (You don't need another database (yet)); extensions (Extensions worth knowing); B-tree (The B-tree does the heavy lifting); more indexes (Beyond the B-tree); EXPLAIN (Read the plan, not the clock); planner (The planner is guessing); plans (The cheapest plan wins); queries (Queries that age well); search (Search without a search engine); functions (Code in the database); concurrency (Everyone waits in line); migrations (Change the schema, keep the site); loading (Load it fast); connections (Connections aren't free); benchmarking (Measure honestly); configuration (The settings that matter); observability (Watch it run); backups (An untested backup is a rumor); security (Trust no tenant); managed (Someone else runs the box); providers (Pick a provider you can leave); playbook (Fix the work, then the box); scale (Scale up before you scale out); replication (Copies of the truth); partitioning (Partition for the delete); sharding (Shard last); limits (Where Postgres loses).

PostgreSQL documentation

The PostgreSQL Global Development Group's manual, version 18 (/docs/18/) unless the entry says otherwise. It's the primary source for nearly every claim in the book, and the first place to look when a version changes.

PostgreSQL source, commits, and wiki

Once the manual has told you what, the READMEs tell you why, in the words of the people who built it. This section holds those design notes, two commits, and the community wiki, all from the PostgreSQL project. Source links point at the master branch, which moves.

Papers

The research behind the mechanisms: write-ahead recovery, isolation, B-link trees, cost-based planning, and the indexes behind vector and hybrid search. You don't need them to run Postgres. Read one when a chapter leaves you asking where a mechanism came from.

Books

Two long-form explanations, both free to read online. They're the best companions to the storage, MVCC, and B-tree chapters when you want the same ideas drawn another way.

Specifications and RFCs

The standards behind the book's advice on identifiers and access control.

Vendor and project documentation

Vendor pages change often, so check the page again before you rely on a price, a limit, or a version. The chapters date the facts they quote, mostly as of October 2026. Entries are grouped by source, with each cited page linked.

Reference works

Articles, talks, and postmortems

Engineering posts, talks, announcements, and incident write-ups, by author or publisher. Read the postmortems first: other teams' outages, told by the people who had them, are cheaper than your own.