Chapter 37 — Key Takeaways

The big idea

Choosing a database is a judgment of fit between your problem and a tool's trade-offs — made with a framework, not by fashion. And the answer, for most applications, is: start with PostgreSQL.

The decision framework

  1. Data model / shape — relational? document? graph? time-series? vector? (The biggest factor — match the data's essential nature, not its surface.)
  2. Workload — OLTP vs OLAP; read- vs write-heavy.
  3. Scale — data size & traffic. Be honest (most apps are smaller than imagined).
  4. Consistency — strong vs eventual (CAP, Ch. 35).
  5. Query patterns — ad-hoc/joins vs key lookups.
  6. Team expertise & operational complexity — can you operate it? (A first-class factor.)
  7. Cost — licensing + infra + people (operating it).
  8. Ecosystem & maturity — drivers, tools, community, hiring.

Weigh them together against actual requirements.

Why PostgreSQL is the default

Fits most business data (relational + extensions: JSONB/FTS/PostGIS/pgvector — theme #4), excellent OLTP, scales far (+ replicas), strong ACID, full SQL, mature/free/operable/everywhere. Start with PostgreSQL; reach elsewhere only for a concrete, demonstrated need.

Polyglot persistence — minimal and justified

Real systems use multiple databases (right tool per part), but every one adds deploy/secure/back-up/monitor/sync cost. Discipline: each addition justified, PostgreSQL as system of record, prefer extensions over new systems, avoid sprawl.

  • Good: add Redis/warehouse/graph only on demonstrated need; one authoritative source. (Case Study 1.)
  • Bad: "best DB per service" by hype → a six-database zoo no one can operate, constant sync/integrity fires. (Case Study 2.)

Common mistakes

Resume-/hype-driven choices; designing for imaginary scale (premature sharding/NoSQL); ignoring the data's essential nature (relational data in a document store); underestimating operational cost (sprawl); not trying PostgreSQL extensions first; treating the choice as permanent (revisit on evidence).

You can now…

  • ☐ Apply a structured framework to choose a database.
  • ☐ Justify PostgreSQL as default and recognize when a factor rules it out.
  • ☐ Design minimal, justified polyglot persistence with a system of record.
  • ☐ Avoid the decision traps; write a reasoned decision document.

Looking ahead — Part VII

Beyond Relational complete. You can design, build, optimize, secure, and choose databases. Chapter 38 — Database Administration opens the final part: operating a database in production — config, monitoring, backups, recovery, tuning, upgrades.

One sentence to carry forward: Choose a database by fit — data shape, workload, scale, consistency, queries, ops, cost — and the answer is almost always "PostgreSQL by default, plus a justified specialist only where a concrete need demands it."