SQL · Queries that survive scale
How do you choose between SQL and NoSQL databases?
Short answer
Choose based on access patterns, consistency, relationships, and scale. Relational databases excel at flexible queries, constraints, and transactions; NoSQL stores optimize for specific access paths.
The useful comparison is relational versus non-relational modelling. Relational engines assume normalized tables, joins, and strong constraints. Document, key-value, wide-column, and graph stores optimize for particular shapes and access paths.
SELECT o.id, o.total_cents, c.email
FROM orders o
JOIN customers c ON c.id = o.customer_id
WHERE c.region = 'EU'
AND o.created_at >= now() - interval '30 days';Where each model fits
- Relational: financial records, inventory, and bookings needing multi-row transactions
- Document: aggregates read and written as a unit, such as a product catalogue
- Key-value: caching, sessions, rate limits, and high-throughput key lookup
- Graph: relationship-heavy traversal such as social connections or fraud rings
NoSQL is not automatically faster or more scalable. A document store often duplicates data to avoid joins, which becomes an application consistency problem. Relational databases scale reads with replicas and writes with partitioning, but cross-shard transactions add complexity.
Follow-ups you should expect
Interviewers use these to check whether the first answer was understanding or memorisation.
- 1When would you denormalize into a document store?
- 2How do you handle transactions across services?
- 3What consistency guarantees do you actually need?
- 4Can a relational database handle large scale?
Say it in the interview
I choose based on access patterns and consistency rather than the label. Relational databases are strong when data is connected, queries are not known in advance, and I need constraints and multi-row transactions. Document or key-value stores are strong when I can model around a known aggregate and accept eventual consistency. I weigh duplication and operational complexity explicitly.
Use this as a model, not a script. Saying it in your own words is what makes it survive follow-up pressure.
Related questions
Reading is step one
Now say it out loud.
Understanding an answer and delivering it under pressure are different skills. Rehearse this topic in a live SQL mock interview and get scored feedback on depth, clarity and confidence.