We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design and AI Engineering, by Roni Das. 984 interactive lessons.
Start LearningFoundation · Database Fundamentals
Databases that don't use traditional table-based relational models. Includes document stores, key-value, graph, and column-family databases.
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.
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.
Learn it in the course
This page is the free part.
₹1,111 in India$25 everywhere elseonce, for the whole course
The System Design course covers NoSQL across a run of lessons, not one page. These 4 alone are about 92 minutes of step-by-step reading, every one with a quiz.
Database model comparison, relational vs non-relational data stores.
Databases that think in JSON, flexible schemas for modern applications.
Wide-column databases like Cassandra and HBase, built for massive scale with flexible schemas.
Distributed SQL databases that promise the scalability of NoSQL with the ACID guarantees of traditional SQL. CockroachDB, Google Spanner, and the NewSQL movement.
all part of
System Design Masterclass
770 lessons · about 287 hours · 18 free to read
₹1,111in India, by UPI
$25everywhere else, by PayPal
It is really nice and good Please join the course
You own this course
Continue with SQL vs NoSQLpay once,
yours for life
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.
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.
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.
Picture Amazon's shopping cart, the system Amazon's original Dynamo store was 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.
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.
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.
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.
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.
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.
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.
Document Stores
Databases that think in JSON, flexible schemas for modern applications
Column-Family Stores
Wide-column databases like Cassandra and HBase, built for massive scale with flexible schemas
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
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.
This page explains the idea. The "SQL vs NoSQL" lesson builds it up step by step, with diagrams. It is part of the System Design Masterclass course, which has 770 lessons. 18 of them are free to read. You pay once and keep it for life, with no subscription.
Open the SQL vs NoSQL lessoncourse 1
From absolute beginner to principal engineer, drawn step by step.
Asked about NoSQL in an interview?
Each question has why it is asked, a full answer, what the interviewer listens for, the follow-ups, the common mistakes and a diagram (268 diagrams in all). A PDF you keep, junior to staff level.
India: UPI, cards or netbanking through Razorpay. Elsewhere: card or PayPal. Download at once from My packs.
