What Is NoSQL? It’s a family of data models other than the classic table, each built for one kind of access pattern. The name suggests they don’t use SQL, but that isn’t the rule. It’s easier to think of NoSQL as a menu of data models than as one product.
The Name Misleads
The usual explanation is “Not Only SQL”. It’s informal, and it works as a memory hook. A NoSQL database doesn’t have to lack SQL, and several offer SQL-like query languages. What they share is a different data model and a different set of trade-offs.
The label became popular around 2009. Web companies needed to spread data over many machines, and a single relational server couldn’t keep up. Some relational features were given up to get that scale. Which ones depends on the product.
Four Data Models
NoSQL covers four common models. I’ll use an online bookstore to show each one.
A key-value store is a giant dictionary. You hand it a key, and it returns a value. The bookstore keeps each shopping cart under the visitor’s session ID. Key-Value and Document Databases: When Each One Fits shows when key-value and document stores each fit. Lookups are fast, but you can’t ask which carts hold a given book unless you planned for that question.
A document store keeps one self-contained record, usually JSON. A book with its title, author, price and reviews sits in one document. One lookup returns the whole book page. Changing one reviewer’s name across every book is harder.
A wide-column store spreads rows across many machines by a partition key. Inside a partition, a clustering key keeps the rows in order. Cassandra tables have named, typed columns, and a column with no value takes no space.
The bookstore logs every page view for every reader. The reader is the partition key, and the time is the clustering key. That’s a heavy stream of writes, and wide-column stores are built for it. You design each table around the query it answers.
Don’t confuse a wide-column store with columnar storage. A wide-column store keeps each row’s values together. Columnar storage keeps each column together for fast totals.
A graph database stores things and the links between them. It answers questions such as which readers share a favorite author.
| Model | Think of it as | Bookstore example | Examples |
|---|---|---|---|
| Key-value | A giant dictionary | Cart stored under a session ID | Redis, DynamoDB |
| Document | One self-contained record | A book with its reviews inside | MongoDB, Couchbase |
| Wide-column | Rows grouped by a partition key and ordered by a clustering key, with sparse values | Page views per reader per day | Cassandra |
| Graph | Things and their links | Readers who share a favorite author | Neo4j |
Photos, messages and audio files don’t automatically need NoSQL. Large files can sit in object storage, with a record about each file in whichever database fits.
The CAP Theorem as a Story
Picture two database nodes, A and B. Both hold the same stock count for a bestselling book: 10 copies. Then the network link between them is cut. The diagram shows what happens next.
A customer buys a copy through node A. Node A can’t reach node B, so it must choose. Choice one is consistency. Node A refuses the sale, or waits until the link returns. Both nodes always agree, but the customer sees an error.
Choice two is availability. Node A accepts the sale and says 9. Node B still says 10 until the link comes back, and then the two sync. That’s eventual consistency. The customer is happy, and for a short time two readers see two answers.
What C, A and P Mean
The CAP theorem puts this story in three letters. C is consistency: every read sees the latest write. A is availability: every request to a working node gets a successful answer, not an error. P is partition tolerance: the network between nodes can split, and the system has to handle it. Computer scientist Eric Brewer proposed the idea in 2000, and Gilbert and Lynch proved a formal version in 2002.
You’ll hear “pick two of three”. That’s misleading. Networks fail, so you can’t drop P. The real choice only appears during a partition: stay consistent or stay available. When the network is healthy, you can have both. Even then, there’s a smaller trade-off between speed and consistency.
NoSQL and ACID
People say NoSQL means no ACID. That’s too broad. MongoDB supports multi-document transactions, and DynamoDB offers a choice between eventually consistent and strongly consistent reads. Cassandra lets you pick the consistency level for each request. Scope and settings matter.
What Eventual Consistency Does Not Mean
Eventual consistency has no deadline attached. It says that if writes stop, all copies converge on one value. It doesn’t excuse your application from handling conflicts. When two nodes took different writes, someone must decide. The latest write wins, the two are merged, or a person reviews them.
Why Not Stay Relational?
The strongest objection to NoSQL is that relational databases already cover a lot of it. They store JSON too, and SQL Server 2025 has a native json data type. SQL Server has had graph tables since 2017. For many applications, one relational database is the right answer.
So, what is NoSQL good for? It pays off in three cases. The access pattern is simple and known, the data is huge, or writes must spread across regions. Even then, you give something up: ad hoc joins, strict schemas, or easy multi-record transactions.
How to Choose
List the queries first. If every query fetches one record by its key, a key-value or document store fits. If many queries join and total things up, a relational database wins. If the main question is how things connect, look at a graph.
Then check what the product guarantees, because the label doesn’t say. Read the documentation for transactions and read consistency before you commit.
What to Remember
What is NoSQL, in one line? It’s a choice of data model made for a specific access pattern. Match the model to your queries, then check the guarantees of the product you pick.
CAP is a story about one moment: the network breaks, and the system picks consistency or availability. Know which one your database picks, and know what your application does about the other.
NoSQL is not one consistency or transaction contract, it is a broad label for different data models.
Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.
Discover more from SQL Authority with Pinal Dave
Subscribe to get the latest posts sent to your email.
