NoSQL is not "better than SQL" — it makes a different trade. Learn what relational databases give up at scale, the BASE vs ACID trade-off, and the four NoSQL families and when each fits.
Relational databases are excellent defaults: strong consistency, flexible queries, and joins. Their strain shows at extreme scale and with certain shapes of data — a single primary node is hard to scale for writes, rigid schemas fight rapidly changing or semi-structured data, and joins across a distributed cluster are costly. NoSQL databases relax one or more of these guarantees to win scale, flexibility, or a specialized data model.
Relational strengths (great defaults):
strong consistency, flexible ad-hoc queries, joins, mature tooling.
Where they strain:
- write scale one primary is hard to scale horizontally for writes
- rigid schema schema migrations fight fast-changing / semi-structured data
- huge scale joins across a distributed cluster get expensive
- special shapes deeply connected (graph) or simple high-throughput lookups
NoSQL = give up SOME of the relational guarantees to win scale, flexibility,
or a data model that fits the problem. It's a trade, not an upgrade.Relational systems favor ACID (atomic, consistent, isolated, durable). Many distributed NoSQL systems instead offer BASE (basically available, soft state, eventually consistent): they stay available and fast, accepting that replicas may briefly disagree. This flows from the CAP theorem — under a network partition you must choose consistency or availability — and many NoSQL stores choose availability. Knowing which your store picks tells you what anomalies to expect.
ACID (relational) BASE (many distributed NoSQL)
Atomic, Consistent, Basically Available, Soft state,
Isolated, Durable Eventually consistent
"always correct, may "always fast + up, may be briefly
block/fail to stay so" out of date across replicas"
CAP theorem: during a network Partition you can keep only ONE of
Consistency or Availability.
CP stores refuse/stall to stay correct (e.g. HBase, MongoDB majority)
AP stores answer, maybe stale, stay up (e.g. Cassandra, DynamoDB)
Pick the store whose trade matches your app. (See CAP in the
Data Modeling / Software Architecture courses.)NoSQL is an umbrella over four quite different data models, each suited to a shape of problem. Key-value stores are hash tables at scale; document stores hold nested JSON-like records; wide-column stores handle massive write-heavy tables by partition; graph databases model relationships as first-class. Matching the family to the access pattern is the whole skill — the rest of this course is one family per lesson.
KEY-VALUE GET/PUT by key. blazing simple lookups. Redis, DynamoDB
use: cache, sessions, counters, feature flags
DOCUMENT nested JSON docs, query by any field. MongoDB, Firestore
use: content, catalogs, user profiles, flexible schemas
WIDE-COLUMN massive tables partitioned by key, Cassandra, HBase,
write-optimized, query by partition. BigTable
use: time-series, events, IoT, huge write throughput
GRAPH nodes + relationships as first class. Neo4j, Neptune
use: social graphs, fraud rings, recommendations
Match the FAMILY to the ACCESS PATTERN, not to hype.The biggest mental shift from relational to NoSQL is this: you do not model the data and then query it — you list the queries first and design the data to serve them. Because most NoSQL stores lack cheap joins and ad-hoc querying, the shape that makes your known reads fast is the right shape, even if it means duplicating data. This "query-first" mindset recurs in every lesson.
Relational: model entities in 3NF, then write any query you need (joins).
NoSQL: list your QUERIES first, then shape the data to serve them fast.
Consequences you must accept:
- denormalize / duplicate data so a read hits ONE place (no joins)
- a new access pattern may need a new table / index / copy of the data
- "what questions will we ask?" is the design input, not "what entities?"
Get the access patterns wrong and a NoSQL schema is painful to change.
Get them right and it scales effortlessly. Query-first, always.