A new service needs a primary datastore. Walk me through how you choose between a relational SQL database and a NoSQL store.
What they are really testing: Whether you choose from the access patterns and consistency needs rather than hype, and whether you understand what each model actually gives up. They want to hear "it depends, and here is on what", with the trade-offs named precisely.
A real interview question
A new service needs a primary datastore. Walk me through how you choose between a relational SQL database and a NoSQL store.
What most people say
drag me
“NoSQL because it scales better and SQL does not scale.”
It treats "scales" as a property of the label rather than the access pattern, and ignores that modern relational databases scale far past most workloads. It shows no analysis of queries, joins, or transactional needs, which are the things that actually decide the choice.
The follow-ups they ask next
Your NoSQL table is fast for the queries you designed, but the product wants a new query the key schema does not support. What now?
NoSQL rewards known access patterns and punishes unknown ones. Options are a secondary index (if the store supports one and it fits), denormalizing/duplicating data into a new item shape, or streaming to a separate query-optimized store. The lesson is that this rigidity is the trade-off you accepted for scale, and a candidate who anticipated it scores well.
When would you pick a relational database even at large scale?
When you need transactional integrity across multiple rows or rich ad-hoc/analytical queries, and the write volume still fits one primary with read replicas (or a managed distributed-SQL option). Money, inventory, and reporting-heavy domains often stay relational because correctness and query flexibility outweigh raw horizontal write scale.
What the interviewer is listening for
- Chooses from access patterns, not the label
- Knows SQL gives joins and ACID, NoSQL gives scale and fixed-key speed
- Pushes back on premature scaling
- Mentions polyglot persistence
What sinks the answer
- Believes "SQL does not scale" as a blanket truth
- Picks NoSQL for scale the workload does not have
- Ignores transactional/consistency needs
- No analysis of query shapes
If you genuinely do not know
Say this instead of freezing. Reasoning out loud from what you do know beats silence every single time, and a good interviewer is listening for exactly that.
“I start from [the access patterns and query shapes]. Relational wins when [rich relationships, ad-hoc queries, multi-row ACID]; NoSQL wins when [fixed key access at high scale, horizontal write scale]. The trade-off: NoSQL gives up [joins and often strong consistency], SQL is harder to [scale writes horizontally]. I also avoid [premature scale] and consider [polyglot persistence] across parts of the system.”
Keep going with data
Senior
Design a highly available web application on AWS. Walk me through the architecture and your trade-offs.
Senior
How do you approach cloud cost optimization without hurting reliability?
Senior
Design a disaster recovery strategy for a revenue-critical workload on AWS. How do you pick between backup-and-restore, pilot light, warm standby, and active-active?
Senior
Design a scalable async processing pipeline for spiky, long-running work (think video transcoding or report generation). Walk me through the queue-based architecture and its failure modes.
Senior
You own a system of many services and an incident took too long to diagnose. Design an observability strategy across the whole estate.
Senior
Design a CI/CD pipeline that lets a team deploy many times a day safely. How do you make production changes low-risk with progressive delivery?
Knowing the answer is not the same as recalling it under pressure
Sign in to send the questions you fumble to spaced recall, so they come back right before you would forget them, and learn the concepts behind them with hands-on labs.
Start free