Chapter 37 — Further Reading

The big picture (everyone)

  • Martin Kleppmann, Designing Data-Intensive Applications — the whole book is, in effect, a decision framework: it equips you to reason about data models, consistency, scale, and trade-offs. The single best companion to this chapter.
  • "Choose boring technology" (Dan McKinley) — the classic essay on preferring proven, well-understood tools (and spending your limited "innovation tokens" wisely). Directly supports the PostgreSQL-as-default and minimal-polyglot themes.

Decision judgment (💻 Developer · 🏗️ DBA)

  • "Just use PostgreSQL" / "PostgreSQL is enough" essays — the widespread practitioner finding that one capable relational database covers most needs (theme #4), and the costs of premature diversification.
  • "Polyglot persistence" (Martin Fowler) — the original framing, and the discipline to keep it justified rather than sprawl (Case Studies 1 & 2).
  • "Resume-driven development" critiques — the anti-pattern of choosing tech for novelty/CV over fit.

Per-database depth (revisit Part VI)

  • Chapters 33–36 of this book — the families and specialized stores this framework chooses among.
  • Vendor "when to use X" guides — read critically; they're written to sell X. The framework is your defense against marketing.

Scale honesty (🏗️ DBA · 💻 Developer)

  • "You probably don't need [microservices / sharding / NoSQL] yet" essays — the recurring lesson that most teams overestimate their scale (Chapter 35's premature-sharding case; Case Study 2 here).

Reference (this book)

  • Chapters 33–36: NoSQL, warehousing, distributed, specialized — the options.
  • Chapter 16: PostgreSQL extensions (JSONB/FTS) that cover many "specialist" needs.
  • Chapter 1: the Lumen case — choosing by hype, the foundational cautionary tale.
  • Chapter 39 — Capstone: your project's database-decision document is part of it.

Do, don't just read

  • Write the decision document for your project (Exercise 37.14): run all factors, state and justify your choice, list justified polyglot additions and the revisit trigger.
  • Critique a real architecture (your own or a public one): which choices were framework-driven, which look hype-driven?
  • For any "we need database X" proposal, ask: which framework factor demands it, and does a PostgreSQL extension cover it?

Next: Chapter 38 — Database Administration — Part VII begins: operating a database in production.