SQL vs NoSQL
Overview
SQL (relational) databases store data in tables with a predefined schema and query it with structured query language, while NoSQL (non-relational) databases trade a rigid schema for flexible data models and easier horizontal scale. Choosing between them is one of the earliest and most common decisions in a system design interview.
Key Concepts
Relational databases organize data into tables of rows and columns with a fixed schema, express relationships through foreign keys, and support joins plus multi-row transactions. They favor strong consistency and structured, related data (see Normalization and Denormalization).
NoSQL is an umbrella for several non-relational models - key-value, document, wide-column, and graph - covered in NoSQL Database Types. These stores relax schema constraints and are built to scale across many nodes rather than one large machine.
Selection criteria
| Selection criterion | Lean SQL when... | Lean NoSQL when... |
|---|---|---|
| Schema stability | Structure is well-defined and stable | Fields vary per record or evolve rapidly |
| Query shape | Ad-hoc queries, joins, aggregations | Known access by key or partition |
| Consistency needs | Strong transactional guarantees required | Eventual consistency is acceptable |
| Write scale | One primary node can absorb the writes | Massive horizontal write volume needed |
| Relationships | Highly relational, many-to-many | Denormalized, self-contained records |
The consistency row maps directly onto the ACID and BASE distinction, and the write-scale row often forces Sharding and Partitioning once a single node is saturated.
Trade-offs
SQL gives you transactional integrity, expressive queries, and a mature tooling ecosystem, but a single primary becomes a scaling ceiling and schema migrations can be costly. NoSQL gives you elastic horizontal scale and schema flexibility, but you frequently push joins, integrity checks, and conflict handling into application code. Neither is universally better; the right answer is workload-dependent, and many production systems use both (polyglot persistence).
Interview Tips
- Anchor the choice to the workload, not the brand: state the access pattern first, then the store.
- Point out that you can combine both - a relational system of record plus a document store or cache for specific views.
- Avoid the traps of claiming NoSQL "can't do transactions" or that SQL "can't scale"; both are too absolute and modern systems blur the line.
Summary
- SQL means relational tables with a fixed schema and strong transactional guarantees.
- NoSQL is an umbrella for key-value, document, wide-column, and graph stores built for horizontal scale.
- Decide with concrete criteria: schema stability, query shape, consistency, write scale, and relationships.
- Consistency needs map to the ACID-vs-BASE trade-off; write scale often forces sharding.
- Real systems frequently mix both stores rather than picking one globally.