SQL vs NoSQL: how to choose a database
SQL and NoSQL are tools for different jobs. Learn what each is good at, the four NoSQL families, and why PostgreSQL is a strong default.
SQL (relational) databases store data in tables with a fixed schema and use joins. NoSQL is a loose name for databases that do not follow that model: they may store documents, key-value pairs, wide columns or graphs.
What SQL gives you
- ACID transactions: a transfer either fully happens or not at all.
- Joins and flexible queries across related data.
- A strict schema that protects data quality.
- Mature tools: PostgreSQL, MySQL, SQLite.
What NoSQL gives you
- Flexible schema: store records of different shapes.
- Easy horizontal scaling for huge volumes, often by design.
- Models that fit specific access patterns.
The four main NoSQL types
| Type | Good for | Examples |
|---|---|---|
| Key-value | caches, sessions, counters | Redis, DynamoDB |
| Document | content, catalogues, user profiles | MongoDB, Firestore |
| Wide-column | huge write-heavy data, time series | Cassandra, HBase |
| Graph | relationships, recommendations | Neo4j |
How to choose
Ask three questions:
- Is the data highly related and does it need transactions? Use SQL.
- Do you know your access pattern and need massive scale or very low latency? Consider NoSQL.
- Is the schema changing constantly? A document store may fit, but PostgreSQL's JSON columns often work too.
A common mistake
Picking NoSQL "because it scales" before you have the traffic. Most products never outgrow one well-tuned PostgreSQL server with replicas. Many real systems use both: SQL for the core data and Redis for caching.
Takeaway: default to a relational database, and add a NoSQL store for a specific job you can name.
Part 7 of 15 in the System Design series. Previous: What is a CDN and how does it make sites faster?.
