"SQL or NoSQL?" is one of the most common system design questions. The honest answer is that it depends on how you read and write your data, not on which one is newer or more scalable. Here is a simple way to decide.
What each is good at
- SQL (relational). Data in tables with a fixed schema, joins between tables, and strong transactions (ACID). Good when data is structured, relationships matter and correctness matters, such as payments, orders and inventory.
- NoSQL. A family of databases that trade some of that for flexibility or scale. They often model data around the way you read it, and many scale out across machines more easily.
The four NoSQL families
| Type | Shape | Good for | Examples |
|---|---|---|---|
| Key-value | Key to value | Caches, sessions, simple lookups at huge scale | Redis, DynamoDB |
| Document | JSON-like documents | Flexible records read as a whole | MongoDB |
| Wide-column | Rows with many sparse columns | Very high write volume, time series | Cassandra |
| Graph | Nodes and edges | Relationship-heavy queries | Neo4j |
A checklist for choosing
- List your queries first. Which reads and writes happen most? A query you cannot answer cheaply is a warning sign for that database.
- Do you need joins and multi-row transactions? If yes, start with SQL.
- How big will it get? A single well-indexed SQL database with read replicas goes a long way. Many products never outgrow it.
- Does the schema change often or vary per record? A document store can fit better.
- What can you afford to be stale? If a slightly old read is fine, you have more options. See the CAP theorem guide.
Myths to avoid in an interview
- "NoSQL scales and SQL does not." SQL scales too, with replication and sharding, though sharding is harder with joins.
- "NoSQL has no transactions." Several NoSQL databases support transactions, with limits.
- "Pick one database for everything." Large systems often use several, each for what it does best.
A safe default to say out loud: start with a relational database because it is well understood, then name the specific access pattern that would make you add something else. Go deeper in the SQL vs NoSQL lesson and the database internals lesson.