Core idea
SQL and NoSQL are not competitors. They solve different problems. The mistake is picking one because it’s trendy. Pick based on access pattern, consistency need, and schema flexibility.
Mental model
SQL = a spreadsheet with strict rules, referential integrity, and powerful queries. NoSQL = a filing cabinet where each drawer can look different and you can add millions of drawers easily. A spreadsheet breaks if you add 10 million rows and need to reorganize the columns. A filing cabinet breaks if you need to join drawers together intelligently.
Why it matters
- Wrong choice here is expensive to fix
- Each type has a specific sweet spot
- Interviewers almost always ask why you chose a particular database
What to know
- SQL (PostgreSQL, MySQL): ACID transactions, complex queries/joins, structured schema → use for financial data, user accounts, inventory
- Document (MongoDB): flexible schema, object-like data, no joins → use for catalogs, user profiles, content
- Key-Value (Redis, DynamoDB): O(1) lookup by key → use for sessions, caching, leaderboards
- Wide-column (Cassandra, HBase): massive scale, time-series, known query patterns → use for IoT, analytics, activity logs
- Graph (Neo4j): relationship-heavy traversals → use for social networks, recommendations, fraud detection
Common traps
- Choosing MongoDB ‘because it’s flexible’ — schema-on-read hides data quality problems
- Using SQL for a write-heavy time-series workload — will not scale
- Assuming NoSQL means no schema — you still need a data model
Recognise it
Recognition trigger: If the interviewer says ‘social network’ → think graph for relationships, SQL for users, Cassandra for activity feed. No single DB fits everything. Design for polyglot persistence.
Practice question
Why would you choose Cassandra over PostgreSQL for a chat message history?
Go deeper
- Chapter 2: Data Models and Query Languages · Designing Data-Intensive Applications (Kleppmann), book