26 NoSQL terms in plain English — what each one means, an example, and the gotcha worth knowing. Covers document, key-value, wide-column, and graph databases.
Last reviewed:
NoSQL"Not only SQL" — an umbrella term for databases that don't use the traditional relational, table-and-JOIN model.
# document (MongoDB), key-value (Redis), wide-column (Cassandra), graph (Neo4j)💡 Not a single technology — the different NoSQL families solve genuinely different problems, not one problem four ways.
schema-lessRecords don't need to follow a predefined, fixed structure — different documents in the same collection can have different fields.
{ "name": "Alice", "role": "admin" }
{ "name": "Bob", "role": "user", "team": "infra" } // extra field, no problem💡 Flexibility shifts validation responsibility to the application layer — the database won't stop you from writing inconsistent data.
CAP theoremA distributed system can only guarantee two of three properties at once: Consistency, Availability, and Partition tolerance.
# during a network partition, a system must choose:
# stay consistent (reject some requests) or stay available (risk stale reads)💡 Since network partitions are unavoidable in practice, the real-world choice is almost always CP vs. AP.
eventual consistencyA guarantee that all replicas will converge to the same value eventually, but reads immediately after a write may return stale data.
# write to replica A succeeds instantly;
# a read from replica B a moment later might still return the old value💡 A deliberate trade-off for higher availability and lower write latency — not a bug, a design choice.
horizontal scalingHandling more load by adding more machines (nodes) to a cluster, rather than making one machine bigger.
# 3 nodes not enough? add a 4th — no downtime, no bigger single server needed💡 The main reason many NoSQL databases exist — they're designed from the ground up to scale this way, unlike most traditional RDBMSs.
documentA single self-contained record, usually stored as JSON/BSON, that can nest arrays and objects instead of splitting data across tables.
{
"_id": "u123",
"name": "Alice",
"addresses": [{ "city": "Kyiv" }, { "city": "Lviv" }]
}💡 The nested addresses array would require a separate table and a JOIN in a relational model.
collectionA group of related documents — the document-database rough equivalent of a table, but without an enforced shared schema.
db.users.insertOne({ name: "Alice" })💡 Documents within one collection commonly represent the same kind of entity, even without a schema forcing it.
embeddingNesting related data directly inside a parent document instead of storing it in a separate collection and referencing it.
{ "order_id": "o1", "items": [{ "sku": "abc", "qty": 2 }] }💡 Great for data that's always read together; bad for data that grows unbounded or is shared across many parents.
referencingStoring an ID that points to a document in another collection, instead of embedding the full related data.
{ "order_id": "o1", "customer_id": "c42" }💡 The document-database analogue of a foreign key — but there's no enforced referential integrity by default.
aggregation pipelineA sequence of processing stages (filter, group, sort, reshape) applied to documents to compute a result — the document-store answer to complex SQL queries.
db.orders.aggregate([
{ $match: { status: "paid" } },
{ $group: { _id: "$customer_id", total: { $sum: "$amount" } } }
])💡 Each stage passes its output to the next, similar in spirit to piping shell commands together.
key-value storeThe simplest NoSQL model — every piece of data is a value retrieved by a unique key, with no query language beyond "get this key".
SET session:abc123 "user_id=42"
GET session:abc123💡 Extremely fast lookups by design, at the cost of no complex queries — you can't ask "find all sessions for user 42" without a secondary index.
TTL (key expiry)Setting a key to automatically delete itself after a specified duration — built into most key-value stores.
SET session:abc123 "..." EX 3600 # expires in 1 hour💡 The standard mechanism behind session storage, rate-limit counters, and cache entries.
in-memory storeA database that keeps all (or most) data in RAM rather than on disk, trading durability for extreme speed.
# Redis, Memcached — sub-millisecond reads💡 Many in-memory stores offer optional persistence (periodic snapshots or a write-ahead log) so a restart doesn't lose everything.
cache-aside patternThe application checks the cache first; on a miss, it reads from the primary database and writes the result into the cache for next time.
value = cache.get(key)
if value is None:
value = db.query(key)
cache.set(key, value, ttl=300)💡 The most common way key-value stores get used alongside a "real" database, rather than replacing it.
wide-column storeA model where each row can have a different, dynamic set of columns, grouped into column families — built for massive write throughput.
# Cassandra, HBase, Bigtable💡 Designed for write-heavy workloads at huge scale — think time-series and event-logging use cases.
partition keyThe field that determines which physical node in the cluster stores a given row — the single most important design decision in a wide-column schema.
# rows partitioned by user_id land on the same node, making per-user queries fast💡 A poorly chosen partition key causes a "hot partition" — one node overloaded while others sit idle.
column familyA grouping of related columns stored together on disk — designed around how the data is queried, not just how it's logically related.
# a "profile" column family and a separate "activity" column family for the same entity💡 Schema design here is query-first: you model the table around the questions you'll ask it, not the entity relationships.
tombstoneA marker written in place of a deleted value, since distributed wide-column stores can't just erase data across every replica instantly.
# a delete doesn't remove data immediately -- it writes a tombstone that gets cleaned up later💡 Too many tombstones accumulating (from frequent deletes) is a well-known Cassandra performance problem.
graph databaseStores data as nodes (entities) and edges (relationships) explicitly, optimized for traversing connections rather than joining tables.
# Neo4j, Amazon Neptune💡 Shines when the interesting question is about relationships themselves — "friends of friends", fraud rings, recommendation paths.
node (graph)A single entity in a graph database — a person, product, or place — that can carry its own properties.
CREATE (a:Person { name: "Alice" })💡 Conceptually similar to a row, but relationships to other nodes are first-class, not a separate join table.
edge / relationshipA directed, typed connection between two nodes, which can itself carry properties (e.g. "since 2020").
MATCH (a:Person), (b:Person)
WHERE a.name = "Alice" AND b.name = "Bob"
CREATE (a)-[:FOLLOWS { since: 2020 }]->(b)💡 Traversing edges is typically O(1) per hop in a graph database, versus an expensive JOIN in a relational one.
traversalWalking from node to node along edges to answer a query — the graph-database equivalent of a JOIN-heavy relational query.
MATCH (a:Person)-[:FOLLOWS*1..2]->(b:Person)
RETURN b💡 A multi-hop traversal that would require several expensive JOINs relationally is often a single fast query in a graph database.
shardingSplitting a large dataset across multiple servers (shards), each holding a subset of the data.
# users A-M on shard 1, users N-Z on shard 2💡 Distinct from replication — sharding splits data for scale; replication copies data for redundancy. Many systems do both.
replica setA group of database nodes holding copies of the same data, for redundancy and read scaling — one primary, the rest secondaries.
# MongoDB replica set: 1 primary (handles writes) + 2 secondaries (replicate + serve reads)💡 If the primary fails, the replica set automatically elects a new one — this is what "automatic failover" means in practice.
quorumThe minimum number of nodes that must acknowledge a read or write for it to be considered successful.
# write quorum of 2 out of 3 replicas = tolerates 1 node being down💡 Tuning read/write quorum is how you trade off consistency, availability, and latency in practice.
denormalizationDeliberately duplicating data across documents/rows to avoid expensive joins at read time — the opposite of relational normalization.
{ "order_id": "o1", "customer_name": "Alice" }
// customer_name duplicated here instead of joined from a customers table💡 A core NoSQL design principle: optimize for how data is read, and accept the cost of keeping duplicates in sync on writes.
Eventual consistency guarantees that all replicas will converge to the same value over time, but a read immediately after a write may still return stale data from a replica that hasn't caught up yet. Strong consistency guarantees every read reflects the latest write immediately, but typically costs more latency and can reduce availability during network issues. Eventually consistent systems trade that immediacy for higher availability and lower write latency — it's a deliberate design choice, not a defect.
CAP theorem says a distributed system can only fully guarantee two of Consistency, Availability, and Partition tolerance at once. Since network partitions are unavoidable in any real distributed system, partition tolerance isn't optional in practice — so the real-world choice during a partition is between staying consistent (rejecting some requests) or staying available (risking stale reads), commonly framed as CP vs. AP.
Sharding splits a dataset across multiple servers so each node holds only a subset of the data, primarily for horizontal scale. Replication copies the same data across multiple nodes for redundancy and read scaling, typically with one primary handling writes and secondaries serving reads and taking over on failover. Many distributed databases use both simultaneously — sharding for scale, replication within each shard for durability.
Embedding nests related data directly inside a parent document, which is efficient when that data is always read together and doesn't grow unbounded — like a few addresses embedded in a user document. Referencing stores just an ID pointing to a document in another collection, which is better when the related data is large, shared across many parents, or queried independently. Unlike a relational foreign key, referencing in most NoSQL databases has no enforced referential integrity by default.
In a wide-column store, the partition key determines which physical node stores a given row — it's the single most important schema design decision. A poorly chosen partition key (e.g. one with very uneven value distribution) creates a 'hot partition', where one node gets overloaded with traffic while the rest of the cluster sits idle, since all rows sharing that key value land on the same node.
A document store (like MongoDB) holds self-contained, often deeply nested JSON/BSON records grouped into collections, and is flexible about structure per document. A wide-column store (like Cassandra) organizes data into rows where each row can have a dynamic set of columns grouped into column families, and is designed specifically for very high write throughput at massive scale, such as time-series and event-logging workloads.
A graph database stores nodes and edges as first-class citizens, so traversing a relationship — walking from one node to a connected node — is typically an O(1) operation per hop. The equivalent query in a relational database requires an expensive JOIN for every hop, and a multi-hop query like 'friends of friends' can require chaining several JOINs that get progressively more expensive as the graph gets deep.
A quorum is the minimum number of nodes that must acknowledge a read or a write for that operation to be considered successful. Tuning the read and write quorum sizes is a direct, practical lever for trading off consistency, availability, and latency — a higher write quorum (e.g. requiring 2 of 3 replicas to ack) makes writes more durable and consistent but slower and less tolerant of node failures.
Denormalization deliberately duplicates data across documents or rows — like storing a customer's name directly on an order instead of joining it from a separate customers collection — to avoid expensive joins at read time, since many NoSQL databases don't support efficient multi-collection joins the way relational databases do. This optimizes for how data is actually read, at the cost of having to keep the duplicated copies in sync whenever the source data changes.
Yes — every term and example on this page is free to read and reference without an account or paywall.