Chapter 33 — Key Takeaways
The big idea
NoSQL databases drop some relational guarantees for scale, flexibility, or specialized access. They expanded the menu — they didn't replace relational. The skill is judgment: relational (PostgreSQL) by default, NoSQL for genuine, specific needs.
The four families
| Family | Example | Best at | Trades away |
|---|---|---|---|
| Document | MongoDB | flexible/variable docs, payloads | joins, integrity, cross-doc transactions |
| Key-value | Redis | fast lookup by key (cache, sessions) | rich queries, joins |
| Column-family | Cassandra | massive write throughput, scale | ad-hoc queries, often strong consistency |
| Graph | Neo4j | deep multi-hop relationship traversal | general-purpose use |
The trades
ACID/strong consistency → BASE/eventual consistency; rich queries/joins → simple access patterns; enforced schema → application responsibility. Trades, not flaws — fit them to the problem.
Theme #4: PostgreSQL often covers it
- Documents → JSONB (Ch. 16); search → full-text (Ch. 16); moderate graphs/hierarchies → joins / recursive CTEs (Ch. 11); key-value → a table (or Redis in front for cache).
- Reach for PostgreSQL's features first — avoid an extra system to deploy/secure/back up/sync.
When NoSQL genuinely wins
- Caching / sub-ms key lookups → Redis (usually alongside PostgreSQL). (Case Study 1.)
- Deep multi-hop graph traversal → graph database. (Case Study 2: relational joins explode past 2–3 hops.)
- Massive write throughput across data centers → Cassandra.
- Scale beyond one server for the right workload → distributed NoSQL/NewSQL (Ch. 35).
The two case-study lessons
- Complement, don't replace (Redis as cache; PostgreSQL stays source of truth).
- Recognize the genuine exception (deep graph traversal needs a graph DB) — move only the part that needs it.
Common mistakes
NoSQL for relational data (the Lumen mistake, Ch. 1); "schemaless" = unenforced schema; replacing PostgreSQL when JSONB/FTS/CTEs would do; ignoring eventual consistency for data that needs strong consistency; polyglot sprawl.
You can now…
- ☐ Name the four families and their best uses + trade-offs.
- ☐ Judge when PostgreSQL covers a "NoSQL" need.
- ☐ Recognize genuine NoSQL wins and which family fits.
- ☐ Avoid fashion-driven NoSQL for relational data.
Looking ahead
Chapter 34 — Data Warehousing. Databases built for analytics: OLTP vs OLAP, star schemas, dimensional modeling, column-oriented storage, and modern analytical databases.
One sentence to carry forward: NoSQL expanded the menu — use PostgreSQL by default (its JSONB/FTS/CTEs cover most "NoSQL" needs), and reach for a document, key-value, column-family, or graph store only for a concrete need it genuinely meets.