Affiliate disclosure

Book titles on this page link to Amazon. As an Amazon Associate, DataField.Dev earns from qualifying purchases — at no additional cost to you.

Further Reading: NoSQL and Specialized Stores

Sources are tagged Tier 1 (confident it exists, recommended without reservation) or Tier 2 (real and worth seeking, but confirm the current edition, version, or URL yourself).

This chapter covered seven store classes in one chapter, which means every section is a compression. The list below is where each one gets its proper treatment.

The general treatment

  • Martin Kleppmann, Designing Data-Intensive Applications, Chapter 2 ("Data Models and Query Languages") and Chapter 3 ("Storage and Retrieval"). Chapter 2 is the best available comparison of relational, document, and graph models — including the observation that the document model's advantages depend heavily on whether your data has a natural one-to-many tree shape. Chapter 3 explains LSM trees versus B-trees, which is the storage mechanism under most of the stores in this chapter. Tier 1.

  • Pramod Sadalage and Martin Fowler, NoSQL Distilled (Addison-Wesley, 2012). Short, and its organizing idea — aggregate-oriented versus relational data models — is the clearest available framing for why document and wide-column stores are shaped as they are. Dated on products, undated on concepts. Tier 2 — old enough that the product landscape has entirely turned over.

Key-value and wide-column

  • Giuseppe DeCandia et al., "Dynamo: Amazon's Highly Available Key-value Store" (2007), SOSP. Recommended in Chapter 4 for quorums; relevant here for the data model and for its candour about what eventual consistency pushes onto application developers. Tier 1.

  • Fay Chang et al., "Bigtable: A Distributed Storage System for Structured Data" (2006), OSDI. The wide-column model's origin — row key, column families, and the sorted-by-key physical layout that makes range queries within a partition cheap. Everything in §12.4 follows from this paper. Tier 1.

  • The Apache Cassandra documentation on data modelling, particularly "Basic Rules of Cassandra Data Modeling." It states plainly what §12.4 compresses: query-first design, one table per access pattern, and denormalization as the model. Reading it is the fastest cure for approaching Cassandra relationally. Tier 2 — versioned.

  • The Cassandra CDC documentation, read specifically to understand why most teams do not use it — per-node commit-log segments requiring cross-replica deduplication. It is a good example of a feature that exists and does not solve the problem. Tier 2.

Document stores

  • The MongoDB change streams documentation. The best non-relational change feed in this chapter, and worth understanding in detail before you build on it: resume tokens, the oplog window (which bounds how long you can be down before you must re-snapshot), and fullDocumentBeforeChange for pre-images. Tier 2 — versioned; pre-image support is version-dependent.

  • The PostgreSQL JSONB documentation and the GIN index chapter. The honest comparison point for §12.10's "absorb before you adopt." Read the operator classes section — jsonb_path_ops versus the default — because it determines which queries an index can serve. Tier 1.

Time-series

  • The Prometheus documentation on "Instrumentation" and "Naming", and the Robust Perception blog post "Cardinality is key." The naming guidance explicitly warns against unbounded label values, which is §12.5's rule, from the source. If one person on your team reads one thing from this list, make it this. Tier 2 — blog; the Prometheus docs themselves are stable.

  • Fabian Reinartz et al. on the Prometheus TSDB design, and the Gorilla paper: Tuan Pham et al., "Gorilla: A Fast, Scalable, In-Memory Time Series Database" (2015), VLDB. Gorilla is where delta-of-delta timestamp encoding and XOR float encoding come from — the mechanisms behind §12.5's compression claims, and genuinely elegant. Tier 1 for Gorilla.

  • The TimescaleDB documentation. The strongest argument for §12.10's absorb-first position on time-series: hypertables, continuous aggregates, and compression inside PostgreSQL. Read the "When not to use TimescaleDB" material if you can find it, which is rarer and more useful. Tier 2.

  • The Elasticsearch guide's "Getting Started" and the relevance/scoring chapters, particularly on BM25. Relevance ranking is the capability you cannot easily rebuild, and understanding BM25 — term frequency, inverse document frequency, and field-length normalization — is what lets you reason about why a search result is ranked where it is. Tier 2 — versioned, and Elasticsearch's documentation is large; use the version selector.

  • The PostgreSQL full-text search chapter, and the pg_trgm extension documentation. The absorb-first option: tsvector/tsquery for stemmed search, pg_trgm for fuzzy and similarity matching. Read them to know where the boundary is before you adopt a search engine. Tier 1.

Vector

  • Yu Malkov and Dmitry Yashunin, "Efficient and robust approximate nearest neighbor search using Hierarchical Navigable Small World graphs" (2016/2018). The HNSW paper — the index behind most vector stores including pgvector. Understanding the recall-versus-speed parameters (M, ef_construction, ef_search) is what turns vector search from a black box into something you can tune. Tier 1.

  • The pgvector repository README. Short, practical, and honest about limits. It documents both HNSW and IVFFlat indexes and when each suits, which is the decision §12.7 defers to it. Tier 2 — a fast-moving project; check the version.

  • Any careful write-up on embedding model versioning and re-indexing. This is the least well-documented part of the vector stack and the part this chapter's second case study is about. The pattern — build alongside, assert coverage, flip — is not vector-specific and is better documented under blue-green deployment than under vector search. Tier 2, and thin.

Graph

  • The Neo4j documentation on Cypher, and any comparison of Cypher to recursive SQL. Worth an hour so you can recognize a genuine graph problem when you meet one — which §12.8 argues is rarer in a data platform than the marketing suggests. Chapter 18 §18.5's recursive CTEs are the comparison point. Tier 2.

On the adoption decision itself

  • Dan McKinley, "Choose Boring Technology." Recommended in Chapter 5 and directly applicable here: the innovation-token framing is the answer to "should we adopt a seventh store." Tier 2.

  • Martin Fowler on "Polyglot Persistence." The essay that named the idea that different parts of an application should use different stores. Read it, and then read §12.1 and §12.10 as the operational counterweight — polyglot persistence is correct in principle and each additional language costs an operator. Tier 2.

If you only read one thing

Read Kleppmann's Chapter 2. About thirty pages, and it will let you look at any store in this chapter and place its data model, which is what makes the extraction and modelling questions tractable.

Then, before your next adoption conversation, read the Prometheus naming and instrumentation guidance — even if you never touch Prometheus. It is four pages, it contains the clearest statement of the cardinality rule in this chapter, and the rule generalizes: a store's cost is driven by the cardinality of the keys you give it, and that is a design decision made by whoever writes the label.