Skip to main content
SQL vs NoSQLlesson 2 of 4 · 3 min read

The NoSQL Families

The label tells you nothing

NoSQL only tells you what a database is not, which is close to useless. Look at the families instead, because each one gave up something specific to buy something specific.

Document stores keep records shaped like the objects in your code, with flexible fields and nesting. The trade is that your data comes pre-joined into the shape of one way of reading it. Fetching a user with their addresses is a single read. Asking which users share an address means looking at all of them.

Key-value stores cut the model down to get and set by key, and hand you back reads measured in microseconds because everything lives in memory. No queries, no relationships, no searching by anything but the key. Sessions, caches, counters.

Wide-column stores group rows under a partition key and keep them sorted inside it, built from the start to spread writes over many machines with no single leader. They swallow enormous write volume, and in exchange you must know your queries before you store anything, because the data is physically arranged per query.

Graph databases make relationships the main thing, so friends of friends who like this is a walk through the data rather than a pyramid of joins. Search engines build a different index entirely, one that ranks text in ways no ordinary index can fake. Time-series stores squeeze timestamped data that only ever gets appended, and throw away old data cheaply.

What every family has in common

Every one of those has the same shape. Each family is a bet on a way of reading that you already know. The relational database is the generalist and these are the specialists.

Specialists win enormously when the work matches the bet and lose embarrassingly when it drifts, which is why this choice belongs to your list of queries and not to a benchmark someone blogged.

the shape of it
Dominant querystart hereRelationalPostgres, MySQLDocumentMongoDB, DynamoDBKey-valueRedis, MemcachedWide-columnCassandra, HBaseSearchElasticsearchGraphNeo4j, Neptunejoins + txnsnested recordsget by keyheavy writestext rankingtraversals
Each family is a bet on one dominant access pattern; the query you run most picks the store.

Worked example

Lena's fleet-tracking startup writes GPS pings into Postgres: 5,000 inserts per second from 30,000 vehicles. At 1.5 billion rows the table's indexes stop fitting in RAM, insert latency triples, and autovacuum runs around the clock. The queries, though, are dead regular: recent pings for one vehicle, ordered by time. That is a wide-column shape. She moves telemetry to Cassandra with partition key (vehicle_id, day) and clustering by timestamp. Writes spread across a 6-node cluster at under 2 ms each, and when the fleet doubles she adds 3 nodes instead of buying a bigger box. Postgres keeps the customers, invoices, and driver records, about 40 GB that never gave anyone trouble. The mistake she avoided: moving everything, when only one table had outgrown the generalist.