In lesson 01-02 we saw the four NoSQL families from very high up: what they are and what they are for, in a couple of paragraphs each. In the previous lesson we understood the reason behind the movement and took our first steps with MongoDB. Now it is time to come down to ground level.

"NoSQL" is not a technology: it is a label that groups together four radically different data models. A document database and a graph database resemble each other about as much as a spreadsheet and a subway map. Saying "we are going to use NoSQL" is as uninformative as saying "we are going to use a vehicle": the useful question is which one, and what for.

In this lesson we tour the four families with real, executable operation: document with MongoDB, key-value with Redis, column-family with Cassandra and graph with Neo4j. For each one we will see its data model, how it is queried, which products represent it, its strengths, its limits and —the thread running through the whole lesson— which piece of BiblioRed fits it. At the end, a comparison table and a decision tree for choosing.

1. The four families at a glance
2. Document databases: MongoDB
3. Key-value databases: Redis
4. Column-family databases: Cassandra
5. Graph databases: Neo4j
6. Specialized families this course does not revisit
7. Comparison table of the four families
8. Decision tree
9. BiblioRed's final split
10. Common mistakes and tips
11. Exercises
12. Conclusion

The four can be ordered by the richness of the structure they understand: from the one that understands nothing about the value it stores to the one that understands the relationships between entities.

And the four pieces of BiblioRed looking for a home:

• Reviews and enriched catalog → rich, heterogeneous structure, queried by content → document.
• Covers and portal sessions → access by key, very frequent, with expiration → key-value.
• Activity log → very high write volume, queried by member and date range → column-family.
• Recommendation engine → traversing relationships between readers and titles → graph.

A warning before we start, so this lesson is not misread: BiblioRed is not going to deploy four databases. It is going to deploy PostgreSQL and MongoDB. Redis, Cassandra and Neo4j appear here because they are the best way to understand what each family solves and because the day BiblioRed grows, it will recognize the moment. Confusing "understanding a family" with "installing it" is the fastest route to an ungovernable architecture.

The unit is the document: a JSON-like structure —stored in BSON, as we saw in 03-01— that allows nesting and arrays. Documents live in collections, which enforce no schema.

Three properties that define the family:

1. The document is self-contained. Everything the application needs to display an entity fits inside it.
2. The engine understands the interior. It can filter, sort, index and aggregate by any field, even a nested one or one inside an array. This is what separates a document database from a key-value store holding JSON: for the latter, the value is an opaque bag of bytes.
3. Writing a document is atomic, with no need for a transaction.

Representative products: MongoDB (the dominant one and our reference), Couchbase, Amazon DocumentDB, RavenDB, Firestore. And an important note: PostgreSQL with the jsonb type does many of these things without ceasing to be relational; we will compare them in detail in lesson 03-04.

We continue with the reviews collection we created in the previous lesson. A filter is a document; each field is a condition and several fields are combined with a logical AND. When the condition is not an equality, the value becomes a document with an operator starting with $.

$exists has no equivalent in SQL, and for a deep reason: in a table, the column always exists; at most it holds NULL. In a collection, a field can simply not be there. It is the difference between "it has no value" and "this entity does not have that concept", and in the document world those are two different things.

The second argument of find is the projection: which fields to return. 1 includes, 0 excludes.

Projection rules worth memorizing:

• You cannot mix inclusions and exclusions in the same projection, with a single exception: _id: 0 can be combined with inclusions.
• The _id is always returned unless you exclude it explicitly.
• .sort(), .limit() and .skip() are chained on the cursor and are equivalent to ORDER BY, LIMIT and OFFSET. In sort, 1 is ascending and -1 descending.

Here a big difference from SQL appears: in MongoDB you do not rewrite the whole document, you apply update operators to parts of it.

Stop for a second on what has just happened. The edited field did not exist in any document in the collection and now it exists in one. No ALTER TABLE was needed, there was no lock and the other three documents never noticed. That is the flexible schema in its most practical form.

The positional operator $ refers to the first element of the array that matched the filter. It is the way to modify one specific element without rewriting the whole array.

Beware of a detail that has caused real incidents: deleteMany({}) with an empty filter deletes the entire collection and asks for no confirmation. In SQL, DELETE FROM table does the same, but at least there is a transaction that can be undone with ROLLBACK. Here, unless you are inside an explicit transaction, there is none.

Summary queries —what we did in lesson 02-05 with GROUP BY— are done in MongoDB with the aggregation framework: a pipeline of stages, where each stage receives documents, transforms them and passes them to the next.

Goal: the average score and the number of reviews for each book, ordered from best to worst.

Stage-by-stage translation, which is the best way to understand it:

Two syntax conventions to fix in your mind:

• "$field" with a leading dollar means "the value of that field", not the literal string. "$score" is the number; "score" would be the text.
• In $group, _id is the grouping key, not an identifier. _id: "$book_id" is literally GROUP BY book_id. If you put _id: null, you group everything into a single row, which is SELECT AVG(...) FROM table with no GROUP BY.

One more example, with $unwind, which has no clean counterpart in SQL: the most used tags.

$unwind has "unfolded" Nuria's review, which had four tags, into four documents identical except for the tag. Then $group counts. It is exactly the work that in the relational model would be done by the intermediate review_tags table we avoided by embedding the array.

Strengths

• Heterogeneous, nested structures with no auxiliary tables and no null columns.
• The schema evolves without a migration.
• Reading a complete entity in a single access.
• A rich query language: filters, aggregation, indexes on any field.

Limits

• Crossing collections ($lookup) is expensive and must not be the norm.
• No declarative referential integrity.
• The 16 MB per document limit bounds what you can embed.
• Multi-document transactions exist, but they cost performance; the design should minimize the need for them.

Fit at BiblioRed: the reviews and the enriched catalog. They are self-contained, heterogeneous entities that are read whole and change shape frequently. It is the perfect fit, and that is why MongoDB is the NoSQL database BiblioRed is actually going to deploy.

The simplest model there is: a giant distributed dictionary. One key, one value. The engine knows nothing about the content of the value —to it, it is a string or a structure, but not something that can be filtered by its interior—.

That radical renunciation buys one thing: speed. Redis keeps all the data in memory and answers in microseconds, with typical figures of more than 100,000 operations per second on a modest machine.

Representative products: Redis (our reference), Valkey (its open source fork), Memcached (simpler still), Amazon DynamoDB (key-value with document capabilities), etcd (cluster configuration).

The star operation of this family is expiration, and it deserves its own section because it is what sets it apart from everything else:

Why expiration is a first-class function. In a relational database, "deleting whatever has expired" is a scheduled job somebody has to write, watch over and run; and while it does not run, the expired data keeps taking up space and polluting queries. In Redis, expiration is a property of the key: the system removes it by itself, with no intervention. For a cache —where stale data is not an error, just useless— and for sessions —where the data has to disappear for security reasons—, that difference is the very reason for choosing the tool.

Redis is not only strings. Its real value lies in its native structures, each with atomic operations of its own.

INCR is atomic: if a thousand members open the record at the same time, the counter ends up at exactly a thousand. Doing this in SQL requires UPDATE ... SET n = n + 1 with its row lock and its transactional cost; here it is a microsecond operation.

A ranking that is always sorted, updated on the spot and queryable in constant time. The relational alternative is an ORDER BY COUNT(*) DESC over millions of rows every time somebody looks at the home page.

Strengths: microsecond latency, atomic operations on structures, native expiration, a model that is trivial to understand and operate.

Limits: you can only query by key (there is no "give me everything with a score of 5"); the data lives in memory, so RAM is both the ceiling and the cost; persistence exists (snapshots and an operation log) but it is meant for recovery, not as a primary store.

Fit at BiblioRed: caching the catalog records and covers —avoiding a trip to MongoDB on every visit to a heavily visited page— and portal sessions —which have to expire by themselves—. Never as the source of truth: if Redis is emptied, BiblioRed must carry on working, only more slowly. That is the acid test of a well-conceived cache.

The name "columnar" is misleading. Here it does not mean "column-oriented for analytics" (that would be ClickHouse or Amazon Redshift), but column families: rows identified by a key, physically grouped together, where each row can have different and very numerous columns.

The two pieces you have to understand are:

• Partition key: it decides which node the row lives on. All the rows with the same partition key are together on the same node and contiguous on disk.
• Clustering key: it decides the order of the rows within the partition.

That physical contiguity is the whole secret: reading "the last 50 events of member 15" is a sequential disk read inside a single partition on a single node. There is no scattered lookup, no JOIN, no coordination between machines.

Representative products: Apache Cassandra (our reference), ScyllaDB (compatible and faster), Apache HBase, Google Bigtable (the 2006 paper that spawned the family), Amazon Keyspaces.

Cassandra is queried with CQL, which is written almost like SQL. That familiarity is a friendly trap: the syntax is similar, the rules are not.

Read that primary key carefully, because it contains the whole lesson:

• (member_id), in parentheses of its own, is the partition key. All of a member's events live together.
• event_date and event_id are the clustering keys: they order things within the partition, from most recent to oldest.
• event_id is there to break ties: without it, two events in the same millisecond would overwrite each other.

Now, the rules that break the expectations of anyone coming from SQL:

Cassandra refuses to run a query it cannot resolve efficiently. There is no free WHERE on any column, no JOIN, no subqueries, and ORDER BY can only follow the clustering order already defined. And that error, far from being an annoying limitation, is one of the product's best design decisions: it warns you in development that your query does not scale, instead of letting you find out in production with ten million rows.

From the previous restriction comes the family's central principle:

In Cassandra you do not design a data model and then query it. You start from the list of queries and create one table per query, duplicating the data as many times as necessary.

If BiblioRed also needs "the most searched terms of a day", you do not add an index: you create another table, with a different partition key, fed by the same write.

To somebody coming from module 5 —which we have not seen yet— this will look like heresy: it is pure and simple duplication. And it is, deliberately. In Cassandra disk is cheap, writes are dirt cheap and what is expensive is the inefficient read. Duplicating is the strategy, not the mistake. It is the most extreme expression of the principle of modeling from the queries that we will study thoroughly in lesson 03-03.

Strengths: extraordinarily fast and sustained writes; linear scaling (twice the nodes, roughly twice the capacity); no primary node —every node accepts writes, so there is no single point of failure—; built-in cross-datacenter replication; native per-row expiration (TTL).

Limits: rigid queries, tied to the key design; no JOINs and no free aggregations; massive duplication that the application has to keep consistent; running a cluster is not trivial; a new query may demand a new table and a reprocessing of the entire history.

Fit at BiblioRed: the activity log. Seventeen million events a year, continuous writes, reads by member and date range, with no need for referential integrity and with value that decays over time. It is the family's canonical use case.

That said, let's stay consistent with what we said in 03-01: 17 million documents a year do not justify deploying and operating a Cassandra cluster. MongoDB absorbs them without difficulty using the bucket pattern we will see in 03-03. Cassandra would come into play if BiblioRed went from a municipal network to a regional one with hundreds of millions of events. Knowing the criterion is what lets you make that decision the day it arrives.

Three elements and that is it:

• Nodes: the entities (a member, a book, an author). They carry one or more labels (:Member, :Book) and properties.
• Relationships: the connections between nodes. They have a type (READ, WROTE), a direction and properties of their own.
• Properties: key-value pairs on nodes and relationships.

The decisive difference from the relational model: in a relational database, a relationship is computed at query time by comparing foreign key values; in a graph database, the relationship is materialized as a physical pointer. Traversing it does not cost a lookup, it costs following a reference. That is called index-free adjacency, and it is the reason deep traversals are so fast.

Representative products: Neo4j (our reference), Amazon Neptune, ArangoDB, JanusGraph, Memgraph.

Cypher reads like a drawing. () is a node, -[]-> is a directed relationship.

This is where the family earns its keep. BiblioRed's business question is: "readers like you also read". Formally: starting from a member, go to the books they have read, from there to the other members who also read them, and from there to the books those members read and ours did not.

That is three hops through the graph.

Look at the first line of the MATCH: it is literally the drawing of the path. You read "I read a book that was read by another who read a suggestion" by following the arrows. And WHERE NOT (me)-[:READ]->(suggestion) is a path anti-pattern: it discards what Marta has already read, just as the anti-join of lesson 02-04 discarded rows with NOT EXISTS.

The SQL equivalent of that query, over module 2's schema, would be roughly:

Six JOINs and a correlated subquery for three hops. It works, it is correct and with BiblioRed's data it will answer fast. The problem is the curve:

Every hop in SQL adds one or more JOINs, and the cost of each JOIN depends on the total size of the tables. In a graph, each hop follows pointers from the nodes you already have: the cost depends on the number of neighbors, not on the size of the database. That is why depth is free in a graph and extremely expensive in SQL.

Practical rule: up to two hops, SQL. From three onwards, and above all if the depth is variable, a graph.

Strengths: deep traversals at almost constant cost; the model is drawn the same way it is thought; relationships with properties of their own; excellent for recommendations, fraud detection, social networks, dependency analysis and family or organizational trees.

Limits: a bad choice for massive aggregations over all the nodes; horizontal scaling harder than in the other families (splitting a graph across machines without cutting relationships is a hard problem); a smaller ecosystem and talent pool; it is usually a secondary database fed from the main one.

Fit at BiblioRed: the recommendation engine. And with the same honesty as before: BiblioRed is not going to deploy it for now; with 12,000 members, a nightly SQL query that precomputes recommendations and leaves them in a MongoDB collection solves the problem with one fewer piece to operate. Neo4j comes in when the recommendations have to be interactive, personalized and of variable depth.

Beyond the big four there are three families that appear constantly in real architectures. We name them so you recognize them, without developing them.

Search engines (Elasticsearch, OpenSearch, Solr). Technically they are document stores, but their engine is built on an inverted index —a structure that goes from each word to the documents containing it—. That gives them relevance ranking, typo tolerance, match highlighting, synonyms and facets. If BiblioRed wanted a professional-grade catalog search, with suggestions as you type and correcting "Jules Verme" to "Jules Verne", this would be the tool. MongoDB has text indexes that cover the basics; a search engine covers the demanding cases.

Time series (InfluxDB, TimescaleDB, Prometheus). Optimized for data of the form (instant, measurement, value) with continuous writes and queries by window. They compress extraordinarily well because contiguous values resemble each other, and they bring interval aggregation and automatic expiration of old data. TimescaleDB is a PostgreSQL extension, which makes it especially convenient if you already have the relational database. BiblioRed's activity log could also live here.

Vector (Pinecone, Weaviate, Qdrant, pgvector). They store numeric vectors —representations of meaning generated by language models— and answer "what is most similar to this?" through nearest-neighbor search. They are the piece that would let BiblioRed answer "I want something like The Map of Time but shorter" without a single word matching. It is the youngest family and the fastest growing.

Pay attention to the last branch: when none of the four families fits clearly, the right answer is relational. That is not a consolation prize, it is professional judgment. We will develop it with more arguments in lesson 03-04.

Bringing together what was decided in 01-02 with what we have seen here:

Two databases, four needs covered and a written criterion for when each deferral stops being reasonable. That deliberate mix of engines is called polyglot persistence; we will name it formally in lesson 03-04 and it will be the complete case study of 08-03.

Mistake 1: using a graph database because the domain "has relationships". Every domain has relationships; that is what the relational model is for. The graph wins when a variable-depth traversal is the main query. A couple of JOINs do not justify another database.

Mistake 2: using Redis as the primary store. It is memory: if the process goes down and persistence was not properly configured, data is lost. Rule: if emptying Redis loses information you cannot rebuild, you are using it wrongly.

Mistake 3: writing CQL as if it were SQL. The syntax is deceptive. In Cassandra there is no JOIN, WHERE only works on the key columns and ORDER BY is tied to the clustering order. If you find yourself writing ALLOW FILTERING to make a query work, the problem is not the query: it is the data model.

Mistake 4: confusing "columnar" with "analytical". Cassandra (column families) is meant for transactional operation at large scale. ClickHouse or Redshift (columnar storage) are meant for OLAP analysis, which we saw in 01-02. They share an adjective and not a purpose.

Mistake 5: using MongoDB's $lookup as if it were a normal JOIN. It works, but it gives away that the document design is not the right one. In the next lesson we will see it cataloged as an anti-pattern.

Tip 1: design your Redis keys with a hierarchical convention. entity:identifier:aspect, for example catalog:MAT-0331:record or session:8f3a2b1c. Without that discipline, in six months nobody will know what is inside a key called m331.

Tip 2: in Cassandra, write the list of queries before the CREATE TABLE. It is the reverse of the relational order and it is mandatory. An unforeseen query can cost you a new table and a reprocessing of the entire history.

Tip 3: try the four families in Docker. An afternoon spinning up Redis, Cassandra and Neo4j in containers and tinkering with twenty documents teaches more than any written comparison. And docker rm -f leaves everything as it was.

Tip 4: every database added is a database to operate. Backups, upgrades, monitoring, permissions, an expert on the team. Before adding the third one, ask yourself whether the problem is not solved with an index in the first.

BiblioRed wants a "Top rated of the month" page with, for each book, its average score and its number of reviews, considering only reviews from April 2026 and showing only the books with an average of 4 or higher. Write the MongoDB aggregation pipeline and its SQL equivalent, and explain which SQL clause each stage corresponds to.

For each of these four new BiblioRed needs, choose the most suitable NoSQL family and justify it in two or three sentences:

• (a) A counter of "copies available right now" per branch, queried on every load of the home page and which has to be extremely fast.
• (b) A history of every status change of every copy (available, on_loan, in_repair, withdrawn), with around 300,000 changes a year, queried as "the history of this copy".
• (c) Detecting informal book clubs: groups of members who repeatedly coincide in reading the same titles in the same weeks.
• (d) Author records with a biography, photo, awards, external links and bibliography, where each author has a different set of data available.

Design the Cassandra table that would answer this BiblioRed query: "show me the last 20 activity events of a specific branch, from most recent to oldest". Write the CREATE TABLE, state which is the partition key and which the clustering key, and answer: why can this table not also answer "the last 20 events of a specific member"?

Solution 1

Solution 2

(a) Counter of available copies → key-value (Redis). Access is always by a known key (available:branch:2), reads are very frequent, the value is tiny and a few seconds of lag are tolerable. INCR/DECR are atomic and answer in microseconds, whereas a COUNT(*) over copies on every home page load is an avoidable waste.

(b) History of copy statuses → column-family (Cassandra). It is a series of immutable events, with continuous writes and a query perfectly known in advance: by copy and ordered by date. Partition key copy_id, clustering key date descending. That said, and to stay consistent with the criterion of section 9: 300,000 changes a year is not much, and a PostgreSQL table with an index on (copy_id, date) would solve this perfectly well for many years.

(c) Detecting informal book clubs → graph (Neo4j). Looking for groups of members densely connected to each other through the titles they share is community detection, a classic graph problem that requires variable-depth traversals. In SQL it would be a repeated self-join of increasing cost; in Cypher it is a path pattern, and Neo4j even ships community algorithms already implemented.

(d) Author records → document (MongoDB). A rich, heterogeneous structure (one author has three awards and no photo, another five links and a long biography), read whole in one go to render the record and queried by its content ("authors born in Vallmar"). It is exactly the same argument that took the catalog to MongoDB, so it also reuses a database BiblioRed already operates.

Solution 3

• Partition key: (branch_id). All of a branch's activity lives together on the same node.
• Clustering keys: event_date (descending, so that the last 20 are the first 20 of the partition) and event_id (to break ties between simultaneous events).

Why it does not work for querying by member. Because member_id is not part of the key: it is an ordinary column. Cassandra needs to know the partition key in order to know which node to go to; without it, it would have to ask every node and filter each entire partition, which is precisely what the engine refuses to do without ALLOW FILTERING.

And this illustrates the family's central rule: one table per query. If BiblioRed needs both views, it keeps both tables —activity_by_member and activity_by_branch— and writes each event into both. The duplication is not a flaw in the design: it is the design.

An additional warning a good designer would see: if a branch generates millions of events, its partition will grow without limit, and unbounded partitions are a known problem in Cassandra. The usual solution is a composite partition key that includes the period, ((branch_id, month), event_date, event_id), bounding each partition to a month. It is the same idea as the bucket pattern we will study in the next lesson.

We have toured the four NoSQL families with real operation:

• Document (MongoDB): BSON documents nested in schemaless collections. Filters with $gt, $in, $regex, $exists, $all; projection with 1/0; sort, limit, skip; partial updates with $set, $inc, $push, $addToSet and the positional $ operator; and the aggregation pipeline as the equivalent of GROUP BY, where $match is WHERE before grouping and HAVING after it, $group groups with _id as the key and $unwind unfolds arrays. Fit: reviews and catalog.
• Key-value (Redis): the engine does not see inside the value and in exchange it answers in microseconds. SET/GET/EXPIRE/TTL, plus native structures —lists, sets, sorted sets, hashes and atomic counters with INCR—. Expiration is a first-class function, and that is why it is the natural tool for caching and sessions. Never as the source of truth.
• Column-family (Cassandra): wide rows grouped by partition key and ordered by clustering key; CQL is written like SQL but forbids JOINs, subqueries and free WHEREs —the ALLOW FILTERING error is a design warning, not a nuisance—. The principle is one table per query, with deliberate duplication. Fit: very high volume activity logs.
• Graph (Neo4j): nodes, relationships with properties and direction, and Cypher, which is written by drawing the path. Index-free adjacency makes the cost of a hop depend on the number of neighbors and not on the size of the database: up to two hops, SQL; from three onwards, a graph. Fit: the "readers like you also read".
• Specialized: search engines with an inverted index (Elasticsearch), time series (InfluxDB, TimescaleDB) and vector stores (pgvector, Qdrant) for semantic similarity search.
• BiblioRed's real decision: PostgreSQL and MongoDB. Redis, Cassandra and Neo4j are deferred with a written criterion for when they would stop being so. Every database added is a database to operate.

We now know which families exist and how each one is operated. What is missing is the hardest part, and the one most often got wrong in practice: designing well. In lesson 03-03, Data Modeling in NoSQL, we will invert the order we learned in the relational world —we will stop modeling the domain and start modeling from the queries—, define the concept of the aggregate, settle the central decision of embedding versus referencing with explicit criteria, study the document patterns (extended reference, subset, bucket, outlier, computed field) and their anti-patterns, and deliver the final, justified design of BiblioRed's collections: reviews, catalog and activity.