SQL vs NoSQL
SQL databases are relational, schema-enforced, and strongly consistent. NoSQL is a grab-bag of non-relational stores built for scale and flexible schemas. Pick by access pattern.
The split between SQL and NoSQL databases is really a split between one well-defined model and everything that deliberately broke from it. SQL databases are relational: data in tables, an enforced schema, relationships by key, queried with SQL, and transactions with ACID1 guarantees. NoSQL ("not only SQL") is the umbrella for the non-relational stores that traded some of those properties for horizontal scale, flexible schemas, or a data model that fits a specific access pattern better.
🔗 Learn more — 1 What is ACID (database transactions)?
What SQL gives you
A relational database2 enforces structure and integrity by construction. The schema is declared, so every row is typed and complete; foreign keys keep relationships honest; joins let you recombine normalized data; and ACID transactions guarantee that concurrent writes don't corrupt each other. Decades of engineering make a single relational node extremely capable. For the vast majority of applications — anything where data is structured and correctness matters — this is the correct default, and "boring relational database" is rarely the wrong answer.
🔗 Learn more — 2 What is a database?
The historical limit was scale: a relational database with strong consistency and joins is hard to spread across many machines.
What NoSQL is, really
NoSQL is not one thing; it is four or five families with little in common except not being a relational table:
- Key-value (Redis, DynamoDB) — a giant dictionary; blazing fast lookups by key, no querying by value.
- Document (MongoDB) — JSON-like documents; flexible, nested, schema-light.
- Column-family / wide-column (Cassandra, HBase) — rows with huge, sparse, dynamic column sets; built for write-heavy scale.
- Graph (Neo4j) — nodes and edges; built for traversing relationships.
What unites them is the motivation: horizontal scale across commodity nodes, schemas that can change per record, and a model shaped to one access pattern. Many achieve that scale by relaxing consistency — favoring availability and eventual consistency (the "BASE" posture) over strict ACID, the tradeoff the CAP theorem forces on a distributed system.
How to choose
Choose by the shape of your access, not by fashion:
- Structured data, relationships, transactions, ad-hoc queries → relational. This covers most applications.
- A single dominant access pattern at massive scale (a session cache, a feed, time-series ingest) → the matching NoSQL store.
- Relationship traversal as the core query ("friends of friends") → a graph database.
Two cautions. First, "NoSQL scales and SQL doesn't" is dated — modern distributed SQL and read replicas scale relational workloads far further than the early NoSQL pitch assumed. Second, schema-flexibility is a loan, not a gift: the structure your document store didn't enforce on write becomes structure your application must handle on read. Reach for NoSQL when a specific access pattern genuinely outgrows the relational model — not as a default.