Part VI — Beyond Relational

"Learn the relational model deeply before you decide you need something else. Then — and only then — you will be able to tell the difference between a problem relational databases solve badly and a problem you are simply modeling wrong."

For five parts this book has made the case that the relational model is right for the overwhelming majority of data problems, and that PostgreSQL in particular can stretch far further than most people realize. Part VI honors that argument by finally testing its limits. There are problems the relational model serves poorly, and there are tools built specifically for them. This part is your guided tour of the modern data landscape — not a dismissive appendix, but five real chapters — so that when you reach for a non-relational tool, you do it for the right reasons.

The thread running through this part is judgment. Every technology here exists because it makes a specific trade-off: a document store trades joins for schema flexibility; a column store trades write speed for analytical read speed; a distributed database trades strong consistency for availability under partition. Knowing the trade-off is knowing the tool.

What you will learn

  • Chapter 33 — NoSQL. The four families — document (MongoDB), key-value (Redis), column-family (Cassandra), and graph (Neo4j) — why they emerged, what each is genuinely good at, and when PostgreSQL (especially with JSONB) does the job better anyway.
  • Chapter 34 — Data Warehousing. OLTP vs. OLAP; the star schema and dimensional modeling; snowflake schemas; slowly changing dimensions; column-oriented storage; and the modern analytical databases (Snowflake, BigQuery, Redshift, DuckDB).
  • Chapter 35 — Distributed Databases. Why and how to distribute: replication and sharding; the CAP theorem and what it really forces you to choose; eventual consistency; two-phase commit; NewSQL (CockroachDB, YugabyteDB); and managed cloud databases.
  • Chapter 36 — Specialized Databases. The right tool for unusual data: time-series (TimescaleDB, InfluxDB), vector (pgvector, Pinecone) for AI embeddings and similarity search, spatial (PostGIS), and search engines (Elasticsearch).
  • Chapter 37 — The Database Decision. A decision framework that ties the whole part together: data model, workload, scale, consistency, query patterns, team expertise, and cost — why PostgreSQL is the right default, and the polyglot-persistence pattern of using several databases in one system.

Why this part matters

This is where the book's most-repeated theme pays off in full: the relational model is right for most problems, and PostgreSQL's full power often eliminates the need for a second database. You will leave Part VI able to say, with evidence, "we don't need MongoDB here — JSONB covers it," and able to recognize the genuine cases where a graph database, a time-series database, or a vector index is exactly right. That judgment — not loyalty to any one technology — is what separates an engineer from a hype-follower.

For every learning path

Every path benefits from the perspective here, but the emphasis differs. 🏗️ DBAs and 💻 developers will weigh Chapters 33 and 35 most heavily (operational reality and scale). 📊 Analysts and data scientists should focus on Chapters 34 and 36 — warehousing and vector/time-series databases are increasingly their daily tools. 🔬 CS students get the theory that exams and interviews love: CAP, consistency models, and storage-engine trade-offs (LSM trees vs. B-trees).

You now know relational databases well enough to look past them honestly. Let's survey the rest of the world — and then learn how to choose.

Chapters in This Part