What Is NoSQL?
For decades, "database" meant a relational database with tables and SQL. In the late 2000s, web companies began to hit limits with that model: data grew too fast for one server, and product teams changed their data structures every week. A new generation of databases appeared to handle these needs, and they became known as NoSQL.
This tutorial explains what NoSQL means, why it emerged, the main NoSQL types, the trade-offs described by the CAP theorem, and how to decide when a NoSQL database is the right choice.
1. What Is NoSQL?
NoSQL describes databases that store data in a model other than relational tables: documents, key-value pairs, wide columns or graphs. Today the name is usually read as "Not only SQL", because many NoSQL databases do support SQL-like queries, and they are often used alongside relational databases rather than instead of them.
NoSQL databases are not one product or one design. What they share is a focus on:
- Flexible data models that do not require every record to have the same fields.
- Horizontal scaling: adding more servers, rather than buying a bigger one.
- High availability through built-in replication across machines and data centres.
- Performance at scale for specific access patterns, such as reading a whole user profile in one request.
2. Why NoSQL Was Created
| Challenge | NoSQL answer |
|---|---|
| Data volumes outgrew a single server | Partition (shard) data across many commodity servers |
| Product requirements and data shapes changed constantly | Schema-flexible documents that can gain fields without migrations |
| Applications work with objects, not rows | Store data in the same nested shape the code uses |
| Users expect the service to be always on, worldwide | Automatic replication and failover across regions |
| New kinds of data: logs, events, sensor data, social graphs | Models specialized for those shapes |
3. The Four Main NoSQL Types
| Type | Data looks like | Examples | Great for |
|---|---|---|---|
| Document | JSON-like documents with nested fields and arrays | MongoDB, Couchbase | General application data, catalogues, profiles, content |
| Key-value | key → value | Redis, DynamoDB | Caching, sessions, leaderboards |
| Wide-column | Partitioned rows with flexible columns | Cassandra, ScyllaDB | Very high write volume, time-ordered data |
| Graph | Nodes connected by relationships | Neo4j, Neptune | Recommendations, fraud detection, networks |
The Types of Databases tutorial covers each of these with examples.
4. The Same Data, Two Ways
Consider a blog post with its author and comments. A relational design splits it into three tables joined at query time. A document design keeps what is read together in one document:
{
_id: ObjectId("6710a1c2e4b0a1b2c3d4e5f6"),
title: "Getting Started with Replica Sets",
author: { name: "Marco Silva", handle: "@marco" },
tags: ["mongodb", "replication"],
publishedAt: ISODate("2026-10-05T09:00:00Z"),
comments: [
{ user: "aditi", text: "Very clear, thanks!", at: ISODate("2026-10-05T11:20:00Z") },
{ user: "ken", text: "How many members do I need?", at: ISODate("2026-10-06T08:02:00Z") }
]
}The page that shows the post can now load everything with a single read. The trade-off: if a commenter changes their display name, you must decide whether old comments keep the old name or get updated. Data modeling in NoSQL is about making these choices deliberately, based on how the application reads and writes data.
5. The CAP Theorem
When data is copied across several servers, a network failure can split them into groups that cannot talk to each other. The CAP theorem says that during such a network partition (P), a distributed system must choose between:
- Consistency (C): every read sees the latest write, or the request fails.
- Availability (A): every request gets a response, even if it might be slightly out of date.
Because partitions cannot be ruled out, real systems are described as leaning towards CP or AP behaviour, and many let you tune the choice per operation. MongoDB, for example, accepts writes only on the primary of a replica set and lets each operation choose its write concern, read concern and read preference, trading a little latency for stronger guarantees or the other way round.
6. ACID and BASE
| ACID | BASE |
|---|---|
| Atomicity: a transaction is all or nothing | Basically Available: the system keeps answering |
| Consistency: rules are never broken | Soft state: data may change as replicas catch up |
| Isolation: concurrent transactions do not interfere | Eventual consistency: replicas converge over time |
| Durability: committed data survives crashes |
Early NoSQL systems often gave up full ACID guarantees for scale, which is where the BASE description came from. That line has blurred: MongoDB has supported multi-document ACID transactions since version 4.0 (and across shards since 4.2), and single-document writes in MongoDB have always been atomic.
7. Data Modeling Is Different
In relational design you normalize data first and write queries later. In document design you start from the queries:
- Embed data that is read together and belongs to one parent, such as order line items inside an order.
- Reference data that is large, shared by many parents or changes independently, such as a product referenced by many orders.
- Avoid arrays that grow without limit inside one document; MongoDB documents have a 16 MB size limit.
- Duplicate small, rarely changing values (like a product name in an order) when it saves a lookup on every read.
8. When to Use NoSQL
| NoSQL is a strong fit when… | A relational database may fit better when… |
|---|---|
| Your data is naturally nested or varies between records | Your data is highly structured and stable |
| You need to scale writes across many servers | One server (plus replicas) comfortably handles the load |
| Access patterns are known and centred on an entity | Users run many unpredictable ad-hoc reports across entities |
| Fast iteration on the data model matters | Strict constraints across many tables are essential |
These are tendencies, not rules. Modern relational databases store JSON, and modern document databases offer transactions, joins ($lookup) and schema validation. Choose based on your data and team, not on labels.
9. Summary
- NoSQL ("Not only SQL") covers non-relational databases: document, key-value, wide-column and graph.
- They emerged to handle huge scale, flexible schemas, object-shaped data and always-on availability.
- The CAP theorem describes the consistency-versus-availability trade-off during network partitions.
- Many NoSQL databases, including MongoDB, now offer ACID transactions.
- NoSQL data modeling starts from how the application reads and writes data.