NoSQL
Databases that don't use traditional table-based relational models. Includes document stores, key-value, graph, and column-family databases.
What is NoSQL?
In short
NoSQL is a family of databases that store data without the rigid table-and-row structure of relational SQL systems. Instead they use flexible models like documents, key-value pairs, wide-column families, or graphs, trading features like joins and strict schemas for horizontal scalability and faster writes on huge, fast-changing datasets.
What NoSQL Actually Means
The name is misleading. NoSQL does not mean "no SQL" and many of these databases now support a SQL-like query language. It originally meant "non-relational," and the working definition today is any database that does not organize data into the fixed tables, rows, and columns that systems like PostgreSQL or MySQL enforce.
There are four main shapes. Document stores keep data as JSON-like records (MongoDB, Couchbase). Key-value stores are a giant dictionary mapping a key to a blob (Redis, Amazon DynamoDB in its simplest mode). Wide-column stores group columns into families and spread rows across many machines (Apache Cassandra, HBase). Graph databases store nodes and the edges between them (Neo4j, Amazon Neptune).
The common thread is a flexible or absent schema. You can store one user record with 5 fields and the next with 40, and the database will not complain. That freedom is the whole point, and also the whole danger.
How It Works Under the Hood
Most NoSQL systems are built to scale out across many cheap servers instead of scaling up one expensive one. Data is split into partitions using a shard key, and a hash or range of that key decides which node owns each record. Add more nodes and the system spreads the load automatically, which is much harder to do with a single relational instance.
To survive a node dying, the same partition is copied to two or three machines. This is where the famous trade-off lives. The CAP theorem says that during a network partition you must choose between consistency and availability. Cassandra and DynamoDB lean toward availability and offer "eventual consistency," meaning a write you just made might not be visible on every replica for a few milliseconds to seconds.
Because there are no joins across machines, NoSQL pushes you to model data around your queries. You denormalize. If a screen shows a user and their last 10 orders together, you store them together in one document, even if that means duplicating order data. Reads get fast because the answer is already assembled; writes get more complex because you may update the same fact in several places.
When To Use It And The Trade-Offs
Reach for NoSQL when you have a clear, high-volume access pattern, a need to scale writes horizontally, or data that does not fit neatly into rows, such as user sessions, event streams, product catalogs with wildly different attributes, or a social graph. A key-value store handling a billion cache lookups a day is a job no single SQL box wants.
Stay with relational SQL when your data is highly connected and you need ad-hoc queries, multi-table joins, and strong transactional guarantees across records, like an accounting ledger or an inventory system that must never oversell. ACID transactions across many entities are exactly what relational engines were built for.
The real cost of NoSQL is paid at design time and at query time. Schema flexibility becomes schema chaos if nobody enforces structure in application code. And because you optimize storage for specific queries, a new query the data was not modeled for can be slow or impossible without rebuilding how you store things. Pick the database for the access pattern, not the hype.
A Concrete Example
Picture Amazon's shopping cart, the system DynamoDB was originally designed for. A cart is fetched and updated constantly, it must never be unavailable during a sale, and a few seconds of staleness is acceptable, far better than an error page that costs a sale.
Modeled in DynamoDB, the user ID is the partition key and the whole cart lives in one item as a key-value record. Reading or writing a cart touches exactly one partition on one set of replicas, so it stays fast and available even when traffic spikes 10x on Prime Day. There are no joins to slow it down.
The same data in a strict relational schema would spread across users, carts, and cart_items tables, requiring joins on every read and locking rows under contention. That model is cleaner on paper but buckles under Amazon's scale and availability needs. The NoSQL version wins here precisely because the access pattern is narrow and well known.
Where it is used in production
Amazon DynamoDB
Powers shopping carts and high-traffic services at single-digit-millisecond latency; the original paper inspired much of modern NoSQL.
Redis
In-memory key-value store used for caching, leaderboards, rate limiting, and session storage across most large web stacks.
MongoDB
Document database storing flexible JSON-like records; widely used for product catalogs, user profiles, and content management.
Apache Cassandra
Wide-column store built for write-heavy, multi-region workloads; Netflix and Discord use it to handle billions of writes per day.
Frequently asked questions
- Is NoSQL faster than SQL?
- For its target workloads, often yes, because it avoids joins and scales reads and writes across many machines. But it is not universally faster. A complex analytical query with many joins usually runs better on a relational database. Speed depends on whether your access pattern matches how the data is stored.
- Does NoSQL support transactions?
- Many modern NoSQL databases now do, but with limits. MongoDB and DynamoDB support multi-record transactions, yet they are usually scoped to a single partition or come with performance costs. Relational databases still offer richer, cheaper multi-table transactions, so use SQL when strong cross-entity guarantees are central.
- What is the difference between document and key-value stores?
- A key-value store treats the value as an opaque blob you can only fetch by its key. A document store understands the structure inside the value, so you can query and index individual fields, like finding all users in a given city. Document stores are key-value stores with query power over the contents.
- Should I use NoSQL for a new project?
- Default to a relational database unless you have a specific reason not to. SQL handles most early-stage needs with strong consistency and easy ad-hoc queries. Reach for NoSQL when you hit a real scaling wall, have a clear high-volume access pattern, or your data is genuinely non-relational like a graph or event stream.
- Can I use both SQL and NoSQL in one system?
- Yes, and large systems usually do. This is called polyglot persistence. A typical stack might keep orders and payments in PostgreSQL for consistency, cache sessions in Redis, store the product catalog in MongoDB, and run the recommendation graph in Neo4j, each picked for its strengths.
Learn NoSQL hands-on
This page explains the idea. The full lesson lets you step through the ring as servers join and leave, read the implementation, and check yourself with a quiz. It is one of 760+ lessons in the System Design Masterclass, from your first API call to distributed consensus. Eleven Foundation lessons are free, no signup. Lifetime access is ₹499 in India or $7.99 worldwide, one payment, no subscription.
Related lessons
Lessons that touch on NoSQL as part of a larger topic.
SQL vs NoSQL
Database model comparison, relational vs non-relational data stores
foundation · core fundamentals
Document Stores
Databases that think in JSON, flexible schemas for modern applications
intermediate · database types storage
Column-Family Stores
Wide-column databases like Cassandra and HBase, built for massive scale with flexible schemas
intermediate · database types storage
LSM Trees
The write-optimized data structure behind Cassandra, RocksDB, LevelDB, and most modern NoSQL databases
intermediate · database types storage
NewSQL Databases
Distributed SQL databases that promise the scalability of NoSQL with the ACID guarantees of traditional SQL. CockroachDB, Google Spanner, and the NewSQL movement
intermediate · database types storage
See also
Related glossary terms you might want to look up next.
SQL
Structured Query Language for managing relational databases. Tables, rows, columns, and powerful joins to query related data.
Database
An organized collection of data that can be easily accessed, managed, and updated. The backbone of almost every application.
BASE
An alternative to ACID for distributed systems: Basically Available, Soft state, Eventually consistent. Trades strong consistency for availability.
ACID
Four guarantees for database transactions: Atomicity (all or nothing), Consistency (valid states only), Isolation (no interference), Durability (changes persist).
Sharding
Splitting a database into smaller pieces (shards) distributed across multiple servers. Each shard holds a subset of the data.
Replication
Keeping copies of the same data on multiple servers. Improves read performance and provides fault tolerance if one server goes down.