When to use SQL vs NoSQL in HLD - Scaling Approaches Compared

Scalability Analysis - When to use SQL vs NoSQL

Growth Table: SQL vs NoSQL Usage at Different Scales

Users / Data Size	SQL Usage	NoSQL Usage
100 users / small data	Simple relational DB works well; easy to manage transactions	May be overkill; simpler key-value stores possible
10K users / moderate data	Relational DB with indexing and read replicas; ACID important	Document or key-value stores for flexible schema; caching helps
1M users / large data	Sharding needed; complex joins slow; scaling write-heavy loads hard	Horizontal scaling easier; eventual consistency acceptable; flexible schema
100M users / massive data	Complex sharding and partitioning; high cost; joins expensive	Distributed NoSQL clusters; high availability; fast writes; schema evolves easily

First Bottleneck

For SQL, the first bottleneck is the database server CPU and disk I/O when handling complex joins and transactions at scale.

For NoSQL, the bottleneck is often network bandwidth and data partitioning consistency as data grows horizontally.

Scaling Solutions

• SQL: Use read replicas for scaling reads, sharding for writes, optimize indexes, and use connection pooling.
• NoSQL: Use horizontal scaling with distributed clusters, partition data by keys, use caching layers, and tune consistency levels.
• Use caching (Redis, Memcached) to reduce DB load for both.
• Use CDN for static content to reduce backend load.

Back-of-Envelope Cost Analysis

Assuming 1M users generating 10 requests per second total (10 QPS):

• SQL DB: Needs to handle 10 QPS with complex queries; may require 1-2 powerful servers.
• NoSQL DB: Can handle 10 QPS distributed across multiple nodes; easier horizontal scaling.
• Storage: SQL needs structured storage with backups; NoSQL needs distributed storage with replication.
• Bandwidth: Depends on data size per request; NoSQL often optimized for smaller, faster operations.

Interview Tip

Start by clarifying data structure and consistency needs.

Explain trade-offs: SQL for strong consistency and complex queries; NoSQL for flexibility and scale.

Discuss expected traffic and data growth to justify scaling choices.

Mention caching and replication as common scaling techniques.

Self Check

Your SQL database handles 1000 QPS. Traffic grows 10x to 10,000 QPS. What do you do first?

Answer: Add read replicas to scale read traffic and consider sharding to distribute write load, because the single DB server will become CPU and I/O bound.

Key Result

SQL databases excel at strong consistency and complex queries but face CPU and I/O bottlenecks at high scale; NoSQL databases scale horizontally more easily with flexible schemas but trade off some consistency.

Practice

1. Which type of database is best suited for data with a fixed schema and strong relationships between tables?

easy

A. Flat file storage

B. NoSQL database

C. SQL database

D. In-memory cache

Solution

1. Step 1: Understand data structure needs

   Data with fixed schema and strong relationships fits well with structured tables.

2. Step 2: Match database type to structure

   SQL databases use tables and enforce schema, ideal for such data.

3. Final Answer:

   SQL database -> Option C

4. Quick Check:

   Structured data = SQL database [OK]

Hint: Fixed schema and relations? Choose SQL [OK]

Common Mistakes:

• Choosing NoSQL for strictly structured data
• Confusing flat files with databases
• Assuming in-memory cache stores persistent data

2. Which of the following is the correct way to describe NoSQL databases?

easy

A. They always use tables with fixed columns

B. They are designed for flexible, schema-less data storage

C. They require strict ACID transactions for all operations

D. They cannot handle large volumes of data

Solution

1. Step 1: Identify NoSQL characteristics

   NoSQL databases allow flexible, schema-less data models.

2. Step 2: Eliminate incorrect options

   They do not require fixed tables or strict ACID for all operations and can handle large data.

3. Final Answer:

   They are designed for flexible, schema-less data storage -> Option B

4. Quick Check:

   NoSQL = flexible schema [OK]

Hint: No fixed schema? NoSQL fits best [OK]

Common Mistakes:

• Thinking NoSQL always uses tables
• Assuming NoSQL can't scale
• Confusing ACID requirements with SQL only

3. Consider a social media app storing user posts that can have varying fields like text, images, or videos. Which database type will likely handle this data best?

medium

A. SQL database with fixed tables

B. CSV files for storage

C. Relational database with strict schema

D. NoSQL document database

Solution

1. Step 1: Analyze data variability

   User posts have varying fields, so schema flexibility is needed.

2. Step 2: Choose database type matching flexibility

   NoSQL document databases store flexible, nested data well.

3. Final Answer:

   NoSQL document database -> Option D

4. Quick Check:

   Variable fields = NoSQL document DB [OK]

Hint: Varying fields? Use NoSQL document DB [OK]

Common Mistakes:

• Choosing fixed-schema SQL for flexible data
• Using CSV which lacks query power
• Confusing relational DB with NoSQL

4. A developer tries to store rapidly changing sensor data with a fixed schema in a SQL database but faces performance issues. What is the likely cause and best fix?

medium

A. Fixed schema causes overhead; use a NoSQL database for flexibility

B. SQL databases are slow; switch to CSV files

C. Sensor data is small; use in-memory cache only

D. NoSQL databases cannot handle sensor data

Solution

1. Step 1: Identify problem with fixed schema and rapid changes

   Fixed schema in SQL causes overhead with frequent schema updates or inserts.

2. Step 2: Recommend flexible schema database

   NoSQL databases handle rapid, flexible data better, improving performance.

3. Final Answer:

   Fixed schema causes overhead; use a NoSQL database for flexibility -> Option A

4. Quick Check:

   Rapid changes + fixed schema = use NoSQL [OK]

Hint: Rapid, flexible data? NoSQL is better [OK]

Common Mistakes:

• Switching to CSV which lacks performance
• Assuming NoSQL can't handle sensor data
• Ignoring schema flexibility importance

5. You are designing a global e-commerce platform that needs to store user profiles, product catalogs, and handle millions of transactions per day. Which database strategy is best?

hard

A. Use SQL for transactions and NoSQL for product catalogs and user profiles

B. Use only SQL for all data to keep consistency

C. Use only NoSQL for all data to maximize flexibility

D. Use flat files for product catalogs and SQL for transactions

Solution

1. Step 1: Analyze data types and needs

   Transactions require strong consistency (SQL), catalogs and profiles need flexibility and scale (NoSQL).

2. Step 2: Combine database types for best fit

   Using SQL for transactions ensures ACID compliance; NoSQL handles flexible, large-scale data efficiently.

3. Final Answer:

   Use SQL for transactions and NoSQL for product catalogs and user profiles -> Option A

4. Quick Check:

   Mixed data needs = hybrid SQL + NoSQL [OK]

Hint: Mix SQL for transactions, NoSQL for flexible data [OK]

Common Mistakes:

• Using only SQL limits flexibility and scale
• Using only NoSQL risks transaction consistency
• Using flat files lacks query and scale support