Summary
SQL databases are best for relational data, transactions, and flexible querying. NoSQL systems are useful for scale, access-pattern-specific models, schema flexibility, or specialized workloads.
Interview Points
- SQL: joins, ACID transactions, constraints, mature query model.
- NoSQL: document, key-value, wide-column, graph, search, time-series.
- Choose based on access patterns, consistency needs, scale, and operational complexity.
- NoSQL does not mean no schema; schema often moves into application logic.
- Polyglot persistence is common in large systems.
2-3 Minute Interview Script
“I do not choose SQL or NoSQL by trend. I choose based on data shape, access patterns, consistency requirements, and scale.
If the data is relational, needs transactions, constraints, ad hoc querying, and strong consistency, a relational database is usually the default. It gives mature indexing, joins, and operational familiarity.
NoSQL makes sense when the workload is better served by a specialized model: key-value for simple high-throughput lookups, document stores for aggregate-oriented JSON data, wide-column stores for massive write scale, graph databases for relationship traversal, or search indexes for text retrieval.
The senior answer is that NoSQL often trades query flexibility and relational integrity for scale or workload fit. I would start with SQL unless the requirements clearly push me elsewhere.”
Follow-Ups
- When does denormalization make sense?
- What consistency model does the product require?