A topic in the Open Knowledge Graph — a free, open map of 15,290 topics and the order to learn them in.
NoSQL ('Not only SQL') databases sacrifice some ACID guarantees in exchange for horizontal scalability, flexible schemas, and high throughput on specific access patterns. Major categories include key-value stores (Redis), document databases (MongoDB), column-family stores (Cassandra), and graph databases (Neo4j). Many NoSQL systems adopt BASE semantics (Basically Available, Soft state, Eventually consistent): replicas may briefly diverge and converge asynchronously, enabling continued operation during network partitions at the cost of potential stale reads.
Map the same data model into a relational schema and a document schema side-by-side, then compare query and update patterns. Explore why joins are avoided in NoSQL by denormalizing data to match dominant read patterns.
You have studied the relational model — tables with fixed schemas, normalized to reduce redundancy, queried with SQL, and governed by ACID transactions. NoSQL databases start from a different set of assumptions. Instead of asking "how do we eliminate redundancy and ensure perfect consistency?" they ask "how do we handle massive scale, flexible data shapes, and access patterns where relational joins become bottlenecks?" The name NoSQL is somewhat misleading — it means "not only SQL," signaling that relational databases are not the only tool, not that SQL is bad.
The four major categories of NoSQL databases each optimize for a different data shape. Key-value stores (like Redis) are the simplest: every record is a value looked up by a unique key, with no structure imposed on the value. Think of it as a giant hash map — blazingly fast for lookups by key, but useless for queries like "find all users in New York." Document databases (like MongoDB) store semi-structured documents, typically JSON, and allow queries on fields within those documents. They are natural for data that varies in structure — one user profile might have a "company" field while another has a "university" field, and neither needs a schema migration. Column-family stores (like Cassandra) organize data by columns rather than rows, making them efficient for queries that read a few columns across millions of rows — common in analytics workloads. Graph databases (like Neo4j) store nodes and edges directly, making relationship traversal a first-class operation rather than an expensive join.
The consistency model is the deepest conceptual shift. Relational databases provide ACID guarantees — after a transaction commits, every reader immediately sees the updated data. Many NoSQL systems instead offer BASE semantics: Basically Available (the system responds even during failures), Soft state (data may be temporarily inconsistent across replicas), Eventually consistent (all replicas converge to the same value given enough time without new updates). This is not sloppiness — it is an engineering tradeoff. When your data is replicated across multiple data centers for availability and fault tolerance, requiring every write to be immediately visible everywhere means waiting for network round-trips to distant replicas before acknowledging the write. BASE relaxes this: a write is acknowledged quickly, and replicas catch up asynchronously.
The decision between relational and NoSQL is not about which is "better" — it is about matching the database to the workload. If your data has complex relationships, requires multi-table transactions, and fits a stable schema, a relational database is almost certainly the right choice. If you need to scale writes across hundreds of servers, your data is naturally hierarchical or varies in structure, and your queries follow predictable access patterns (look up by key, fetch a document by ID), NoSQL systems can provide dramatically better performance and operational simplicity. Many modern applications use both — a pattern called polyglot persistence — keeping transactional data in PostgreSQL, caching hot data in Redis, and storing event logs in Cassandra.