Overview

Each family optimizes a different access shape: key-value for single-key lookups, document for nested, self-describing records read as a whole, wide-column for partition-scoped rows ordered by a clustering key, and time-series for append-heavy, timestamp-keyed range scans. Graph databases are deliberately excluded -- they are their own sibling topic (graph-databases), not a NoSQL family this topic covers.

The access pattern, the horizontal-scale need, and the consistency the application can actually tolerate. A relational store's joins-plus-ACID default is the right choice for many workloads; NoSQL earns its place only when one of those three specifically does not fit -- not by default, and not because a name sounds more modern.

Under a network partition, a distributed system must trade consistency for availability -- it cannot guarantee both. This is Gilbert & Lynch's 2002 formal proof of Brewer's original conjecture: a partitioned node can either refuse to answer (favoring consistency) or answer with possibly-stale data (favoring availability), but not both at once.

CAP only describes the trade-off DURING a partition. PACELC (Abadi, 2010) adds the ELSE branch: even with no partition at all, a distributed system still trades latency for consistency on every normal operation -- a synchronous, consistency-favoring write is slower than an asynchronous, latency-favoring one, partition or not.

Basically Available, Soft state, Eventually consistent. Many NoSQL stores default to BASE because guaranteeing full ACID (especially cross-node isolation and durability) at scale costs coordination latency that conflicts with the availability and horizontal-scale goals those stores were built for -- BASE is a deliberately looser contract traded for those goals, not an oversight.

It promises that replicas converge to the same value over time, given no new writes. It explicitly does NOT promise synchronous coordination on every write, or that a read immediately after a write on a different replica returns the latest value -- a reader can observe a stale value for some window before convergence completes.

N is the number of replicas a piece of data is stored on; R and W are how many replicas must acknowledge a read or write, respectively, for that one operation to succeed. A client dials consistency versus latency per call by choosing R and W -- read/write at ONE for low latency and weaker consistency, or at QUORUM (or ALL) for stronger consistency at the cost of waiting on more replicas.

It means naming the application's actual dominant reads and writes FIRST, then shaping documents, partition keys, and indexes specifically to serve those named patterns efficiently. It replaces starting from a normalized entity-relationship diagram and hoping the queries fall out naturally -- that relational-first instinct produces a schema optimized for data integrity, not for the specific reads a NoSQL store will actually serve.

It buys read speed: the common read becomes a single fetch of one document or row instead of a join across multiple tables. It costs write-side duplication -- the same fact now lives in multiple places, so a write that changes it must update every copy, and an inconsistency between copies becomes possible if that update is incomplete.

A good partition key distributes rows, documents, or items EVENLY across nodes, so no single node carries disproportionate load. A bad choice -- one with low cardinality, or one that concentrates writes on a single popular value (a celebrity user ID, a single "global" counter key) -- creates a hot partition: one node absorbs far more traffic than its peers, becoming a bottleneck the rest of the cluster cannot help with.

Plain modulo hashing (hash(key) % node_count) remaps NEARLY EVERY key when a node is added or removed, because node_count itself changed. Consistent hashing places both nodes and keys on a hash ring, so adding or removing one node only remaps the keys that fall in that node's own small arc of the ring -- the Dynamo paper's own technique for minimizing data movement during cluster resize.

One leader accepts and orders every write; followers replicate the leader's write stream and can serve reads (at the cost of some replication lag). On leader failure, a follower is promoted to become the new leader -- failover -- and the cluster resumes accepting writes through the newly promoted leader.

Any replica can accept a write directly -- there is no single leader coordinating write order. A client's read or write then targets a QUORUM of replicas (per co-07's R/W/N), and the client or coordinator reconciles whatever the queried replicas return, the Dynamo-style approach that trades a single point of write coordination for the read/write quorum doing the reconciling instead.

LWW compares the timestamp attached to each concurrent write and keeps the one with the latest timestamp, discarding the rest. Its silent cost is exactly that discarding: the losing write's data is gone with no merge, no conflict flag, and no chance for the application to reconcile the two updates -- whichever write happened to have the later clock value wins, even if that is purely an artifact of clock skew.

Vector clocks detect whether two writes are causally ordered (one happened strictly after the other, so it should win outright) or CONCURRENT (neither happened-before the other, so which one is "correct" is genuinely ambiguous). What vector clocks explicitly do NOT do is resolve the conflict themselves -- they surface it, leaving the application to decide how to merge two concurrent, causally-unordered updates.

Conflict-free replicated data types are designed so that concurrent updates merge DETERMINISTICALLY, with no application-level conflict-resolution code required at all -- a G-counter's merge is always "take the max per replica," a set union is always "union both sets." The structure of the data type itself guarantees the merge is well-defined and produces the same result regardless of merge order.

In a distributed, partitioned store, a secondary index (one not on the partition key) either has to be maintained across every partition on every write, or a query using it has to fan out to every partition at read time -- both add coordination cost a single-node relational index never has to pay, because a single-node index update never needs cross-node coordination in the first place.

No schema is enforced by the engine at write time by default -- two documents in the same collection can have entirely different fields. "Schema-on-read" means the READER is responsible for interpreting whatever shape it finds, which buys flexibility to evolve document shape without a migration, at the cost of pushing shape-validation responsibility into application code (or an optional schema validator) instead of the database engine.

The aggregation pipeline is a staged, server-side sequence of operators ($match, $group, $lookup, and others) that transforms, groups, and even joins documents entirely on the server, returning only the final, already-computed result. A plain find() returns raw documents the client must then filter, group, or join itself -- the aggregation pipeline moves that work server-side instead of pulling raw data across the network first.

Typed structures let the SERVER perform structure-aware operations atomically and efficiently -- appending to a list, incrementing a hash field, or reading a sorted set's top N members all happen server-side in one round trip. Storing everything as an opaque blob would force the client to fetch the whole blob, deserialize it, mutate it, and write the whole thing back, losing both atomicity and efficiency.

As a cache: TTL-based eviction is the norm, and losing the data on a crash is acceptable because it can be recomputed or re-fetched from the system of record. As a durable store: persistence (RDB snapshots and/or AOF write-ahead logging) is tuned so data survives a restart or crash, because there is no other system of record to fall back on -- the engine is identical, but the durability configuration and the acceptable-loss assumption are opposite.

A partition key determines WHICH node (or partition) a row or item lives on -- all rows sharing a partition key land together. Within that one partition, a clustering key (Cassandra) or sort key (DynamoDB) determines the ORDER rows are physically stored and read back in -- which is why a partition-scoped, clustering-ordered read is cheap, while a query that does not name the partition key is not.

Single-table design stores multiple different entity types (e.g., users, orders, products) in ONE physical DynamoDB table, distinguishing them via deliberately overloaded partition-key and sort-key prefixes (e.g., USER#123 vs. ORDER#456). The decision to do this should be driven entirely by the application's own NAMED access patterns -- which entities need to be fetched together in one query -- not applied reflexively as a DynamoDB "best practice" independent of what the application actually reads.

A TTL attribute marks an item or key for automatic deletion once a stated expiry time passes, freeing the application from writing an explicit cleanup job. Cassandra relies on per-row TTL as its own CLOSEST built-in equivalent to retention -- unlike TimescaleDB's dedicated retention-policy mechanism (co-30), Cassandra has no store-level retention concept beyond per-row TTL.

Writes land first in an in-memory memtable, which is periodically flushed to an immutable on-disk SSTable; a background compaction process later merges SSTables to reclaim space and bound the number a read must check. This append-only path buys high write throughput (writes never do an in-place disk seek) at the cost of write amplification (compaction rewrites the same logical bytes multiple times) and read amplification (a read may need to check several SSTables before finding the latest value) -- a B-tree's in-place updates avoid both amplifications but pay a random-seek cost per write instead.

Polyglot persistence means DELIBERATELY using different stores for different services or access patterns within one system, because no single engine serves every access pattern well. It is not the same as picking a trendy database per service arbitrarily -- the "deliberately" is load-bearing: each store choice should trace back to that service's own access pattern and consistency needs (co-08, co-02), not to novelty.

It let a NoSQL store guarantee ACID-style atomicity and isolation across MULTIPLE keys, documents, or rows in one operation -- something the earliest NoSQL stores explicitly did not offer, single-item writes only. It still costs latency: coordinating a multi-item transaction requires more cross-node agreement than a single-item write, so it is reached for only when the access pattern genuinely requires atomicity across more than one item, not by default.

Because the license determines what you are actually allowed to do with the software -- a source-available, non-OSI-approved license like MongoDB's SSPLv1 carries real obligations (extending copyleft to any "as a service" offering built around the software) that a permissive license like Apache-2.0 or BSD-3-Clause does not. Adopting a store without checking this (DD-15) risks a legal and architectural surprise discovered only after the store is already load-bearing in production.

Time is the PRIMARY axis the storage engine itself is organized around (chunk/partition boundaries follow time, not an arbitrary key), because the workload is append-heavy and timestamp-keyed. The dominant read is a range scan over a time window ("give me every point between these two timestamps"), which is exactly the shape the engine's own time-partitioned chunking is built to serve efficiently.

A retention policy DROPS raw data entirely once it passes a stated age window. Downsampling instead ROLLS high-resolution raw points into coarser, pre-aggregated buckets (e.g., per-minute readings into hourly averages) -- retention discards data outright, while downsampling keeps a lossy, cheaper-to-scan summary of it instead of the raw points.

A plain downsampling query (a GROUP BY time_bucket(...)) recomputes its rollup from raw points EVERY time it runs. A continuous aggregate instead maintains that rollup INCREMENTALLY and PRE-COMPUTED, as new raw data lands -- so a range query against it reads already-summarized buckets directly, never re-scanning the underlying raw points at query time.

OLTP is write-heavy, point-transaction-shaped, and expects millisecond latency per operation (a single row read or write). OLAP is read-heavy, analytical-scan-shaped -- it touches many rows but typically few columns per query -- and tolerates second-to-minute latency, because the workload is aggregation over a large dataset, not a single-row transaction.

Storing each column's values contiguously on disk lets a query that references only a few columns read ONLY those columns' own bytes, skipping every other column entirely -- a row-oriented layout forces reading whole rows regardless of how few columns a query names. The same columnar layout also compresses better, because values within one column tend to be far more similar to each other (repeated categories, sorted timestamps) than values across a whole heterogeneous row.

Instead of processing one row at a time through each operator, a vectorized engine processes a whole BATCH (a "vector") of column values at once per operator call. This improves CPU cache locality (a contiguous batch of same-typed values fits cache lines efficiently) and enables SIMD instructions (single-instruction-multiple-data) to apply the same operation to many values in one CPU cycle, both unavailable to a naive row-at-a-time execution loop.

Parquet is an open, columnar, ON-DISK file format -- data at rest. Arrow is a columnar, IN-MEMORY format -- data while being processed. They work together because Parquet's own on-disk column-chunk layout maps directly onto Arrow's in-memory columnar layout, letting a reader load a Parquet file straight into Arrow buffers with minimal transformation, and letting Arrow-aware engines (like DuckDB) query an in-memory Arrow table with zero-copy interchange -- no serialize-then-copy round trip.

A wide-column store (Cassandra, DynamoDB) is row/PARTITION-oriented on disk -- an entire row lives together, tuned for fast, partition-scoped operational reads and writes. A columnar OLAP store (DuckDB, ClickHouse) is genuinely COLUMN-oriented on disk -- each column's values live together, tuned for analytical scans over many rows and few columns. Conflating them leads to real mistakes: expecting a wide-column store to efficiently answer a cross-partition analytical aggregate (it cannot, without an explicit escape hatch like ALLOW FILTERING), or expecting a columnar OLAP store to efficiently answer a single-partition point lookup the way a wide-column store's partition routing does.

The counter key is a hot partition (co-10) -- every write in the whole system routes to the SAME partition key, so no amount of horizontal scaling helps, because the bottleneck is one node's own write capacity, not the cluster's aggregate capacity. The fix is to shard the counter itself (e.g., N sub-counters incremented round-robin, summed on read) or use a CRDT counter (co-16) designed for exactly this high-concurrency-increment shape.

Last-write-wins (co-14) was the wrong conflict-resolution strategy for a cart, because the two writes were CONCURRENT (co-15) -- neither happened causally after the other -- and both carried real, non-conflicting information (two different items added) that LWW's "keep one, discard the other" behavior cannot merge. A vector clock would have DETECTED the concurrency and let the application merge both additions, or a CRDT (a set-union-based cart, co-16) would have merged them automatically with no application-level conflict code at all.

A secondary index in a distributed, partitioned store (co-17) is not "free" the way a single-node relational index is -- maintaining it costs real, ongoing write-side coordination across partitions on EVERY write to the indexed column, whether or not that index is ever actually queried. If status is rarely queried, the index's ongoing write cost likely outweighs its rare read benefit -- the team should reconsider whether denormalizing status into a purpose-built lookup table (co-08, co-09) for the few reads that need it would cost less overall.

The team should have checked and recorded MongoDB's ACTUAL license (co-28, DD-15) before building a managed-service offering on top of it -- SSPLv1 is source-available but explicitly NOT OSI-approved, and its terms extend copyleft-like obligations specifically to services offered "as a service" around the software, a materially different commitment from Apache-2.0 or BSD-3-Clause. "Open source" is not one uniform legal category; the exact license text is what actually governs what you may do.

This is an OLAP workload (a read-heavy, many-row, analytical aggregate) running against a store tuned for OLTP (co-32) -- Cassandra's wide-column, partition-oriented layout is not built for a cross-partition analytical scan, which is exactly why such a query either requires ALLOW FILTERING (a full-cluster scan) or performs poorly. The fix is to ETL the relevant data into a purpose-built columnar OLAP store (DuckDB, ClickHouse; co-33, co-36) and run the analytical report there, leaving the OLTP cluster free to serve checkout traffic.

Retention (dropping raw data past a stated age window) and downsampling (rolling high-resolution points into coarser, pre-aggregated buckets), both first-class, built-in features of a purpose-built time-series store like TimescaleDB (co-30) -- rather than something the application must hand-roll after the fact. A continuous aggregate (co-31) would additionally have kept range queries fast by reading pre-computed rollups instead of re-scanning an ever-growing set of raw points.

They skipped access-pattern-first modeling (co-08) -- single-table design (co-23) is meant to be DERIVED from the application's own named, dominant access patterns up front (overloading partition-key and sort-key prefixes specifically to serve those patterns in one query), not retrofitted onto a relational-shaped schema after the fact. Naming the actual queries first, then designing keys and indexes to serve them, avoids the escalating GSI-bolt-on pattern this team fell into.

It is not a bug -- it is co-36's own distinction made concrete. Cassandra's wide-column layout and query planner are BUILT for partition-scoped operational reads; a cross-partition aggregate is structurally outside that design, so the planner requires an explicit ALLOW FILTERING opt-in as an honest admission that the query will scan every partition. DuckDB's columnar layout is BUILT for exactly this shape (a GROUP BY over a subset of columns across many rows), so it needs no such guardrail -- the "requires a flag" versus "just works" difference IS the architectural difference between the two layouts, not an inconsistency between them.

CAP and PACELC answer different questions that both matter in practice: CAP names the trade-off a system is FORCED into during a genuine partition (an emergency condition), while PACELC names the trade-off a system CHOOSES on every single normal operation, partition or not. A team needs CAP's vocabulary to reason about failure-mode behavior and PACELC's vocabulary to reason about everyday latency/consistency tuning (co-07's R/W/N) -- collapsing them into "just PACELC" would lose the useful distinction between an emergency trade-off and a routine one.

LWW and vector clocks solve genuinely different problems: LWW picks a winner and silently discards information, while vector clocks detect a conflict and preserve BOTH pieces of information for the application to merge. "Faster" implies they are interchangeable answers to the same question with different costs -- they are not. The right lens is whether losing the discarded write's data is actually acceptable for that specific field (a last-write-should-win status flag) or not (two independently-added shopping cart items, AP2) -- that decision, not raw speed, should drive the choice.

Denormalizing without first naming the dominant access pattern risks optimizing the wrong read -- duplicating data into an aggregate shape that serves a query the application does not actually run often, while leaving the ACTUAL dominant query still requiring a join or a second fetch. Naming the access pattern first turns denormalization from a guess into a targeted decision: embed or duplicate specifically what the NAMED dominant read needs, not whatever seems convenient to combine.

A secondary index pays its cost UP FRONT, continuously, on every write to the indexed column, regardless of how often the index is later queried. ALLOW FILTERING pays its cost AT QUERY TIME instead -- each individual query that uses it triggers a full-cluster scan, with no ongoing write-side overhead between queries. The right choice depends on frequency: a column filtered often justifies an index's continuous write cost; a column filtered rarely is often cheaper served by an occasional ALLOW FILTERING scan than by paying an index's cost on every write whether queried or not.

TTL is set PER ROW, at write time, and each row expires independently on its own schedule -- it is a fine-grained, per-item mechanism with no awareness of the table's overall shape. A retention policy operates at the CHUNK or PARTITION level, dropping an entire time-partitioned chunk once its whole window ages out, in one operation -- a coarser-grained, engine-native mechanism purpose-built for a time-series store's own chunk structure. The practical difference shows up at scale: dropping one chunk is far cheaper than expiring millions of individually-TTL'd rows one at a time.

Graph databases are excluded entirely because nothing else in this topic depends on graph-traversal concepts to be taught honestly. LSM-trees are different: understanding WHY Cassandra and other wide-column stores accept higher write and read amplification in exchange for write throughput (co-25) is necessary to explain their real access-pattern tradeoffs (co-08, co-22) -- you cannot honestly teach "why does Cassandra reject a query that skips the partition key" without first establishing what compaction and amplification are. The boundary is drawn at "how would I IMPLEMENT an SSTable's compaction strategy" (that belongs entirely to database-internals-and-storage-engines), not at "why does this trade-off exist" (that belongs here, because it is load-bearing for everything else this topic teaches about wide-column stores).