Skip to main content
One question that appears in almost every system-design interview is: choose SQL or NoSQL for your design and explain why. The key to a strong answer is not just naming a database family — it’s justifying that choice from your access patterns and the guarantees your application needs.

​
Answer framework

A concise, persuasive justification typically covers:
  • The structure of your data (entities and relationships).
  • The queries and access patterns you must support (especially joins and complex reads).
  • Consistency and transactional guarantees required by the application.
  • How you would handle other workload types (real systems often combine SQL and NoSQL stores).

​
What to explain (quick checklist)

  • Data model: Is it relational (users, photos, follows) or schemaless/document-oriented?
  • Query shape: Do you need multi-table joins, aggregations, or secondary indexes?
  • Transactions: Are atomic, multi-row updates necessary for correctness?
  • Scale and latency: Do you need multi-region reads/writes or extreme write throughput that requires sharding?
  • Operational tradeoffs: How will you do backups, replication, and failover?

​
Example concise justification

“My data is relational — users, photos, and follows are connected. To build a home feed I must combine these entities, which implies joins and transactional consistency. Therefore a relational SQL database makes sense for the core social graph. If I later add a high‑volume, schemaless stream such as analytics events, I would store that separately in a NoSQL store optimized for ingestion and OLAP.”

​
What earns points in an interview

  • Start from access patterns (reads, writes, queries, joins), not buzzwords like “it scales.”
  • Explain why joins, transactions, or schema enforcement are necessary for correctness.
  • If you propose NoSQL, be specific: what about SQL fails for this workload? (e.g., multi-region latency, write hotspot that requires consistent hashing/sharding, or highly variable record schemas).
  • Describe how you will handle consistency and transactions under a NoSQL choice (e.g., single-shard transactions, application-level compensation, or CRDTs).
  • Acknowledge hybrid approaches: identify which parts map to SQL vs NoSQL and why.

​
Avoid weak answers

Do not answer “NoSQL because it scales” without follow-up. Interviewers will ask: what prevents SQL from meeting the requirements? How would you partition, replicate, or increase capacity? What consistency tradeoffs will you accept?

​
Remember ACID

Before an interview, be ready to state which of the ACID properties your system requires and why:

​
Quick workload → store mapping

​
Suggested short answer template you can adapt in an interview

  1. Describe the data model and primary access patterns (reads, writes, query shapes).
  2. Explain whether joins and multi-row transactions are required; if yes, favor SQL.
  3. If choosing NoSQL, state the scalability or schema reasons and how you’ll handle consistency/transactions.
  4. Mention other components and where they would live (e.g., SQL for core relational data, NoSQL for logs/analytics).
  5. Conclude with operational considerations: sharding, replication, backups, expected latencies, and monitoring.
Keeping the answer focused on access patterns and guarantees demonstrates both technical understanding and practical design sense.
When you justify a database choice, explicitly tie ACID (or relaxed consistency models like eventual consistency / BASE) to your application needs — for example, whether user-facing actions require strict transactions or whether background analytics can tolerate eventual consistency.

Watch Video