SQL vs NoSQL — FAANG-Level Cheat Sheet

1. 🧱 Data Model (STRUCTURE)

SQL

Tables (rows + columns), strict schema. Normalized (split data, use joins).

🧠 Analogy: Excel sheets with fixed columns

NoSQL

Flexible (JSON, key-value, graph, etc.) Denormalized (store together)

🧠 Analogy: JSON files / flexible folders

🎯 FAANG Question

Q: How would you design user + orders data?

SQL Answer:

Users, Orders tables. Join via user_id.

NoSQL Answer:

Store orders inside user document

{
  "userId": 1,
  "orders": [...]
}

⚠️ Missing Insight

• Denormalization = faster reads but duplication risk
• SQL normalization = consistency but join cost

---

2. 📐 Schema Flexibility

SQL

Schema first → strict. Changes = migrations.

NoSQL

Schema-less. Add fields anytime.

🎯 FAANG Question

Q: Startup with changing requirements?

Answer: Use NoSQL initially (fast iteration). Migrate to SQL later if needed.

⚠️ Missing Insight

Schema-less ≠ no schema → handled at application level. Bad design → messy data over time.

---

3. 🔗 Relationships

SQL

Strong relationships (foreign keys). JOIN support.

NoSQL

No joins (mostly). Use embedding or manual joins.

🎯 FAANG Question

Q: When to avoid joins?

Answer: At large scale (billions of rows) → joins are expensive. Prefer denormalized NoSQL.

⚠️ Missing Insight

Joins don't scale horizontally well. That's why big systems move away from them.

---

4. 📈 Scalability

SQL

Vertical (bigger machine). Horizontal = hard (sharding).

NoSQL

Horizontal (add servers easily).

🧠 Analogy:

• SQL = upgrade 1 server 🖥️
• NoSQL = add more servers 🖥️🖥️🖥️

🎯 FAANG Question

Q: Why is SQL hard to scale?

Answer: ACID + joins + transactions across nodes = complex. Requires sharding + coordination.

⚠️ Missing Insight

Modern fix: NewSQL — Google Spanner, CockroachDB.

---

5. ⚖️ Consistency (ACID vs BASE)

SQL → ACID

Strong consistency. Transactions guaranteed.

🧠 Example: Bank transfer

NoSQL → BASE

Eventual consistency. Temporary inconsistency allowed.

🧠 Example: Instagram likes count delay

🎯 FAANG Question

Q: Design Instagram likes system?

Answer: Use NoSQL (eventual consistency OK). Slight delay acceptable.

⚠️ Missing Insight

CAP Theorem: SQL → CP, NoSQL → AP.

---

6. ⚡ Performance

SQL

Strong for complex queries (joins, analytics).

NoSQL

Strong for simple, high-scale reads/writes.

🎯 FAANG Question

Q: Logging system (millions writes/sec)?

Answer: Use NoSQL (e.g., wide-column store).

⚠️ Missing Insight

Query-first design in NoSQL → design schema based on queries.

---

7. 🔍 Query Capabilities

SQL

JOIN, GROUP BY, analytics.

NoSQL

Limited queries. No joins → multiple calls.

🎯 FAANG Question

Q: Complex reporting system?

Answer: Use SQL (analytics + aggregation).

⚠️ Missing Insight

NoSQL often paired with: Elasticsearch for search, Data warehouse for analytics.

---

8. 🛠️ Development Speed

SQL

Slow start, stable long-term.

NoSQL

Fast start, risky long-term.

🎯 FAANG Question

Q: MVP product?

Answer: Start with NoSQL → iterate fast.

⚠️ Missing Insight

Many companies: Start NoSQL → migrate to SQL later.

---

9. 🧠 Real-World Use Cases

SQL

• Banking
• E-commerce orders
• Inventory

NoSQL

• Social media
• Logs / analytics
• Caching

🎯 FAANG Question

Q: Design YouTube?

Answer: SQL → user, payments. NoSQL → video metadata, views, recommendations. Cache → fast delivery.

---

10. 🔥 Most Important (INTERVIEW GOLD)

🟡 Polyglot Persistence

👉 Use BOTH

🎯 FAANG Question

Q: Design Uber?

Answer: SQL → payments, rides (critical). NoSQL → location updates (high volume). Cache → active drivers.

⚠️ Missing Insight (VERY IMPORTANT)

Real systems NEVER use only one DB. Combine based on use-case.

---

🧠 FINAL DECISION FRAMEWORK (1-LINER)

👉 Use SQL if:

• Strong consistency needed
• Complex queries
• Structured data

👉 Use NoSQL if:

• Massive scale
• Flexible schema
• High throughput

👉 Use BOTH if:

• Real-world large system (FAANG)

⚡ ULTRA-SHORT MEMORY TRICK

• SQL = Consistency + Structure
• NoSQL = Scale + Flexibility

---

Top 25 FAANG-Level SQL vs NoSQL Questions

1. 🔥 SQL vs NoSQL — when to use what?

Answer:

• SQL → strong consistency, relationships, complex queries
• NoSQL → scalability, flexible schema, high throughput

👉 "If correctness matters → SQL. If scale matters → NoSQL."

---

2. ⚖️ ACID vs BASE?

Answer:

• ACID (SQL) → strict correctness
• BASE (NoSQL) → eventual consistency

🧠 Example: Bank → ACID. Instagram likes → BASE.

---

3. 📦 Why NoSQL scales better?

Answer:

• Built for horizontal scaling (sharding)
• No joins → easier distribution

👉 "NoSQL avoids cross-node coordination."

---

4. 🔗 Why joins are bad at scale?

Answer:

• Require data from multiple nodes
• Network + coordination overhead

👉 "Joins break horizontal scalability."

---

5. 🧱 What is denormalization?

Answer:

• Store related data together

🧠 Example: User + orders in one document

👉 Trade-off: Faster reads. Data duplication.

---

6. 📐 Why schema-less is powerful?

Answer:

• No migrations
• Fast iteration

👉 "Great for unknown or evolving data."

---

7. ⚠️ Downside of NoSQL?

Answer:

• Weak consistency
• No joins
• Data duplication

👉 "You move complexity to application layer."

---

8. 🏦 Why SQL for banking?

Answer:

• Transactions must be atomic
• No inconsistency allowed

👉 "Money cannot be eventually consistent."

---

9. 🌍 CAP theorem in DB choice?

Answer:

• SQL → CP (Consistency + Partition tolerance)
• NoSQL → AP (Availability + Partition tolerance)

👉 Trade-off: Strong consistency vs availability.

---

10. ⚡ Which DB for high write system?

Answer:

• NoSQL (e.g., wide-column)

👉 Example: Logs, telemetry, IoT.

---

11–25 Quick Answers

#	Question	Answer
11	Which DB for analytics?	SQL (aggregations, joins, GROUP BY)
12	How to scale SQL?	Read replicas + sharding + caching
13	Eventual consistency example?	Social media likes, profile updates
14	Why NoSQL faster for simple reads?	No joins, direct key lookup O(1)
15	How to design NoSQL schema?	Design based on query patterns first
16	Why SQL better for ad-hoc queries?	Flexible query engine, supports unknown queries
17	Can NoSQL support transactions?	Yes, limited (MongoDB). Slower/less common
18	What is polyglot persistence?	Use multiple databases per use-case
19	Design Facebook feed — which DB?	NoSQL: massive scale, high write/read throughput
20	Design Uber — DB choice?	SQL → rides/payments, NoSQL → location, Cache → active drivers
21	Why SQL struggles with sharding?	Transactions + joins across shards are complex
22	What is NewSQL?	SQL + horizontal scaling (Spanner, CockroachDB)
23	Why NoSQL avoids joins?	Joins expensive in distributed systems
24	When NOT to use NoSQL?	Financial systems, strong consistency, complex reporting
25	When NOT to use SQL?	Massive scale, rapid schema changes, real-time high throughput

---

🚀 FINAL INTERVIEW ONE-LINER

👉 "SQL is for correctness and relationships. NoSQL is for scale and flexibility. Real systems use both."