Choosing a Database: SQL vs NoSQL
Intermediate · 18 min read · High-Level Design, Storing Data
Relational, key-value, document, wide-column and graph stores — and how to choose.
Choosing a database is one of the most consequential decisions in a design — data outlives code, and migrating stores later is painful. In interviews, "SQL or NoSQL?" is less a question about technology than about whether you understand your data model, access patterns, and consistency needs.
The right way to frame it is not "SQL vs NoSQL", but: what are the queries, how much data, how fast does it grow, and what guarantees do I need?
Relational databases (SQL)
Relational databases (PostgreSQL, MySQL, Oracle, SQL Server) store data in tables of rows and columns with a fixed schema. Relationships are expressed via foreign keys and combined at query time with joins.
NoSQL families
"NoSQL" is an umbrella for non-relational stores. They are not one thing — each family optimises for a different access pattern.
Side-by-side comparison
How to choose
Ask these questions in order:
Polyglot persistence
Large systems usually use several stores, each for what it does best. An e-commerce platform might use:
NewSQL: the middle ground
Distributed SQL databases — Google Spanner, CockroachDB, YugabyteDB, TiDB — offer SQL, ACID transactions, and horizontal scaling, by combining sharding with consensus replication (Raft/Paxos). The trade-offs: higher write latency (each write needs a quorum, possibly across regions), operational complexity, and cost.
Interview questions
- Design a banking ledger. SQL or NoSQL?
- Why do wide-column stores require you to design tables around queries?
- What are the downsides of denormalisation in a document store?
- Can you get transactions in NoSQL databases?
Practice
Write your answer before opening the suggested one. If you mark it "Partly" or "Missed it", it comes back in your review deck.
Further reading
Key takeaways
- Choose a store based on access patterns, consistency needs and scale — not on labels.
- Relational databases give ACID transactions, joins and flexible querying; they're harder to scale for writes.
- Key-value for fast lookups, document for whole-entity access, wide-column for massive time-ordered writes, graph for multi-hop relationships.
- Default to relational and justify any deviation with a specific requirement.
- Real systems are polyglot; keep stores in sync via CDC or events from a single source of truth.