10. SQL vs NoSQL | Difference between SQL & NoSQL | SQL Vs NoSQL Tutorial | SQL, NoSQL system design

SQL vs NoSQL | Difference between SQL vs NoSQL | SQL Vs NoSQL Tutorial | SQL vs NoSQL system design

Today i am covering very important System Design Interview question, which is
SQL vs NoSQL, it has been asked in many big product based companies HLD round like Amazon, Google, Facebook, Microsoft etc.

SQL databases
SQL (structured query language) databases are essentially relational databases, meaning that data is organized in terms of their relationships with other data.

NoSQL databases
NoSQL (not only SQL) databases, on the other hand, are non-relational. There are several types of NoSQL databases, such as column-oriented, graph-based, document-oriented, and key-value store databases

I have also discussed, which DB to choose and what criteria we need to see before choosing the particular type of DB.

You will also get to know about Advantage and Disadvantage of SQL and NoSQL both.

Pls Note: Notes are missing for this topic

Join this channel to get access to perks:

#systemdesign #interviewpreparation #interviewquestions
#SQL #nosql

[TheRoamingCompassOfficial]

The main difference is that if you want to achieve acid property go for sql else go for no sql. Interviewer will try to confuse you regarding replication and distribution it can be also achieved in sql. No sql is also preferable to storing huge data

[lakshyasharma]

Hi Shreyansh,
Following your content for sometime, and have to admit that you're addressing all the topics which are highly probable in an interview in a very structured format. It's also really great to see how you're balancing this with your office work. Keep up the good work, and I wish you good health 👍

[kunalsevkani]

But Now NoSQL databases like mongoDB have caught up so well with complex queries in form of aggregation pipelines and schema validated collection to ensure structure. Do you think we need to revisit our understanding before the interview?

[krishnaagarwal]

### Summary
In the video, Shreyansh outlines the key differences between SQL (Structured Query Language) and NoSQL databases, and provides guidance on when to use each type. The presentation is structured around four main criteria: structure, nature, scalability, and properties of both SQL and NoSQL. SQL is defined as a query language used with relational databases that organize data in tables with rows and columns, emphasizing a predetermined schema. On the other hand, NoSQL encompasses various database architectures such as key-value stores, document databases, column-family stores, and graph databases, highlighting its flexibility in storing unstructured data without a fixed schema.

Key distinctions also include how SQL databases maintain data integrity and relationships through the ACID properties (Atomicity, Consistency, Isolation, Durability), ensuring data integrity in transactions. In contrast, NoSQL databases follow the BASE model (Basically Available, Soft state, Eventual consistency) and can be distributed across multiple nodes, allowing for high availability and flexibility at the cost of some transactional consistency. Shreyansh concludes by outlining scenarios for when to choose SQL or NoSQL based on data integrity needs, relational data structures, and query complexity, providing a comprehensive overview for those preparing for technical interviews or database-related projects.

### Highlights
- 🔍 **Structured vs. Unstructured**: SQL uses structured data models with tables, while NoSQL offers flexible structures, such as key-value pairs and graphs.
- 💡 **ACID vs. BASE**: SQL databases maintain data integrity through ACID properties; NoSQL databases follow BASE for high availability but may sacrifice immediate consistency.
- 📊 **Scalability**: SQL databases typically scale vertically, while NoSQL solutions can easily scale horizontally across multiple servers.
- 🔗 **Data Relationships**: SQL is well-suited for relational data requiring complex queries, whereas NoSQL is optimized for unstructured or semi-structured data.
- ⚙ **Use Cases**: SQL is ideal for applications requiring strong consistency and relationships (like transactional systems), while NoSQL fits scenarios needing flexibility and performance (like big data applications).
- 🌍 **Decentralization**: NoSQL databases can distribute data across multiple nodes, enhancing availability and performance.
- 🛠 **Performance**: SQL can struggle with high traffic due to its structure, while NoSQL can handle large amounts of data with ease.

### Key Insights
- 📚 **Data Structure Significance**: SQL's rigid structure with predefined schemas provides data integrity and clarity, which is crucial for applications that depend on relationships among data points. The requirement of a predetermined schema in SQL means developers must meticulously plan their database structure ahead of time, while NoSQL's flexible structures allow for rapid iterations and changes in data organization without extensive redesign.

- 🌱 **Scalability Advantages**: SQL databases have limitations when it comes to scaling up. They prefer vertical scaling—which can be costly and hardware-dependent—for performance improvements. In contrast, NoSQL can grow horizontally, allowing the addition of more servers to handle larger volumes of data and transactions without a significant drop in performance.

- ⚖ **Transaction Management and Data Integrity**: SQL’s adherence to ACID principles ensures reliable transactions, making it heavily favored in financial systems where a single transaction’s integrity is paramount. NoSQL’s reliance on eventual consistency processes like BASE models meets the needs of less critical applications that can afford a slight delay in data synchronization, making it better for applications that prioritize speed and scalability over strict consistency.

- 🤝 **Choosing the Right Database**: When considering whether to use an SQL or NoSQL database, it is essential to evaluate the nature of the data and application requirements. If the application necessitates complex multi-table relationships, SQL is the better option. Conversely, if the application demands flexible data handling, scalability, or deals with large datasets that vary in structure, NoSQL is more suitable.

- 🔄 **Performance Under Load**: As databases scale, SQL systems may experience performance degradation due to their fundamental design. In contrast, NoSQL architectures often deliver superior performance under heavy loads because of their inherent design to distribute data and queries across multiple nodes, enabling faster data access and retrieval rates.

- 🌍 **Big Data and Flexibility**: NoSQL systems embrace the concept of "big data, " accommodating datasets that may include varying types and structures. Their ability to handle unstructured data seamlessly caters to modern applications, such as social media and real-time analytics, which frequently require rapid shifts in data structure.

- ⚠ **Potential Drawbacks of NoSQL**: Developers should also be aware that the use of NoSQL databases, while advantageous in many scenarios, may lead to complexities in ensuring data accuracy and integrity after replication across distributed systems. She discussed eventual consistency concerns, whereby users might retrieve outdated or inconsistent data at times, emphasizing the need for applications to handle these realities in design and user experience.

In summary, understanding both SQL and NoSQL databases is critical for anyone engaged in software development, data management, and system architecture. The choice between these technologies hinges on specific project needs regarding data structure, integrity, availability, and query complexity, all of which were articulated succinctly by Shreyansh in his detailed explanations.

[shubamgoswami]

quality is top notch but just one feedback from my side (as a engineer we are owl who do not sleeps at night and do all learnings at night ) this whiteboard gives a litte bit stress to the eyes beacuse i am following your lld playlist and watching uour videos for atleast 1 hr daily so please can you make future videos with greyish background it will be more effective

[magicalchemical]

Excellent explaination Shreyansh, one feedback would be take 1-2 inerview questions at the end of each topic and let other know your approach to solving them. This would give us directons on how to approach a problem with the things that we have learned from the topic. it would be like like a complete prep.

[adityagupta]

It would have been great if you could take some examples like a case study to explain your point regarding flexible query...a system where flexible query will be required and a system where it won't be required similarly for 2nd point of relational and non relational data.

[navraj]

@30:31 it is confusing..i saw it some where else which is diffeernt from what you said sir.. Which One to Use?
✅ For simple searches (structured data, primary key lookups) → SQL
✅ For complex searches (full-text, fuzzy, relevance-based ranking) → NoSQL (MongoDB, Elasticsearch)

Since you work with ElasticSearch, it's the best choice for post search queries, as it provides:
✔ Full-text search
✔ Filters for post type, date range, etc.
✔ Fuzzy search & relevancy ranking
✔ Scalability for large datasets

For basic queries on structured data, SQL is fine, but for advanced search, NoSQL solutions like Elasticsearch or MongoDB Atlas Search are much better.

[priyadarshinir]

Hi Shreyansh,
Thanks for this video!
it would have even more helpfull if u would have taken some system design examples and mentioned which one can be used with what in the end.

[dhruvkaran]

bro u just nailed, wish you healthy life bro

[suheabkhan]

Next video should be indepth details of caching

[hariommewada]

hey shreyansh you have done marketiing by telling that your vedios are free. but you have made most important vedios private.

[piyushmathpal]

you mention sql is preferably vertically scalable and not horizontal. 
Since scaling vertically has a limit, how does then bank and other security db handle enormous users?

[asktostranger]

Bus bahya podh do
Details course bana ke 😍💘

[sahilseewal]

Thanks for all your videos in HLD, they are really good. I will really appreciate if you can share these scribed notes that you use for explaining.

[arishtajain]

It is not entirely correct to say that SQL databases cannot be used when high availability and high performance are required. Distributed databases like Cassandra, Google Spanner are designed to scale SQL databases and offer high availability by replication, redundancy, and failover mechanisms.
The most important determinant is the kind of data to be stored, and the relationship between the data.
Modern day software solutions offer scalability options for both SQL and noSQL databases.

[tusharmittal]

# 📊 SQL vs NoSQL – Complete Comparison Notes

This comparison is based on **four key dimensions**:

1. Structure
2. Nature
3. Scalability
4. Properties

---

## ✅ 1. SQL (Structured Query Language)

SQL databases are **relational** and follow a **tabular format** with a **predefined schema**.

---

### 🔹 A. Structure

| Feature | Description |

| Tables, Rows, Columns | Data is stored in structured tables with predefined rows and columns. |
| Fixed Schema | Schema must be defined before inserting data. |
| Relationships | Supports relationships between tables using **foreign keys**, **joins**, etc.|

**Example:**
```sql
CREATE TABLE Users (
ID INT PRIMARY KEY,
Name VARCHAR(100),
Email VARCHAR(100)
);
```

---

### 🔹 B. Nature

| Feature | Description |

| Centralized (General Case) | Data generally resides on a single server in traditional implementations. |
| Sharding Exists | SQL databases support sharding but not as seamlessly as NoSQL. |

> In typical deployments, data is **centrally located**. Though sharding is supported (e.g., MySQL with Vitess), it requires additional configuration.

---

### 🔹 C. Scalability

| Type | Description |

| **Vertical Scaling** | Increase RAM, CPU, or storage of a single server. |
| **Horizontal Scaling (Limited)** | Involves partitioning data across servers (e.g., by rows), but is complex and not native in many SQL databases. |

> Most SQL databases are better suited to **vertical scaling**.

---

### 🔹 D. Properties (ACID)

SQL databases follow the **ACID** properties to ensure data integrity:

| ACID Property | Description |

| **A - Atomicity** | Transactions are all-or-nothing. |
| **C - Consistency** | Ensures database remains valid before and after transaction. |
| **I - Isolation** | Concurrent transactions do not interfere with each other. |
| **D - Durability** | Once committed, data will survive crashes. |

> These make SQL databases ideal for **financial and transactional systems**.

---

## 🚀 2. NoSQL (Non-relational)

NoSQL databases offer **schema-less**, **scalable**, and **highly available** storage, suitable for large-scale and unstructured data.

---

### 🔹 A. Structure

There are **four major types** of NoSQL databases:

| Type | Description | Example |

| **Key-Value Store** | Stores data as key-value pairs. Values are opaque to queries. | DynamoDB |
| **Document Store** | Stores data as documents (e.g., JSON). Supports querying on document fields. | MongoDB |
| **Column Store** | Stores data in columns rather than rows. Different keys can have different columns. | Cassandra, HBase |
| **Graph DB** | Stores data as nodes and relationships (edges). Good for relational data like social graphs. | Neo4j |

#### 📘 Examples:

- **Key-Value**:
`{"user123": "John Doe"}` — can't query by "John" directly, only by key (`user123`).

- **Document**:
```json
{
"user_id": "user123",
"name": "John Doe",
}
```
You can query by `name`, `email`, etc.

- **Columnar DB**:
```
RowKey: user123

RowKey: user456
Columns: name=Jane
```

- **Graph DB**:
Nodes represent people, and edges (relationships) represent "friends with", "follows", etc.
Ideal for social networks (e.g., friend recommendations).

---

### 🔹 B. Nature

| Feature | Description |

| Distributed by Default | Data is spread across multiple nodes/clusters. |
| Decentralized Storage | Supports high availability and fault tolerance. |

> Unlike SQL, most NoSQL systems are **designed to be distributed first**.

---

### 🔹 C. Scalability

| Type | Description |

| **Horizontal Scaling (Primary)** | Easily scale out by adding more servers/nodes. |
| Built for Scale | Handles massive amounts of data with ease. |

> This makes NoSQL a great choice for **Big Data** and **high-throughput systems**.

---

### 🔹 D. Properties (BASE)

NoSQL databases follow **BASE** properties:

| BASE Property | Description |

| **B - Basically Available** | The system is always available (even during failures). |
| **A - Soft state** | System state can change over time without input (due to eventual sync). |
| **E - Eventual consistency** | Data becomes consistent over time after updates. |

#### 🧠 Explained via Example (Dynamo-style):

- **Basically Available**:
You can always fetch data, either from the **coordinator node** or one of its **replicas**.

- **Soft State**:
State may temporarily differ across replicas but will converge over time.

- **Eventual Consistency**:
You may receive **stale data** briefly, but over time, all nodes **sync using gossip protocols** (like in consistent hashing), and latest data becomes available.

---

## 🔄 SQL vs NoSQL: Summary Table

| Feature | SQL | NoSQL |

| **Structure** | Tabular (Tables, Rows, Columns) | Key-Value, Document, Column, Graph |
| **Schema** | Fixed schema | Schema-less or dynamic |
| **Data Model** | Relational | Non-relational |
| **Scalability** | Vertical (mostly) | Horizontal |
| **Consistency** | Strong (ACID) | Eventual (BASE) |
| **Query Capability** | Flexible joins, subqueries | Limited queries, need known fields |
| **Ideal Use Case** | Financial apps, transactional systems | Big Data, caching, social apps, large-scale ops|
| **Availability** | Lower in partition failures | High availability by design |
| **Performance** | Slower for massive unstructured data | High performance for distributed data |

---

## 🧩 When to Use What?

| Requirement | Preferred Database |

| Relational data, joins, ACID compliance | ✅ SQL |
| High data integrity (e.g., banking) | ✅ SQL |
| Dynamic or unstructured data | ✅ NoSQL |
| High availability & fault tolerance | ✅ NoSQL |
| Large-scale data with high throughput | ✅ NoSQL |
| Caching layer (e.g., Redis) | ✅ NoSQL (KV Store) |
| Inconsistent tolerance is acceptable | ✅ NoSQL |

---

## 🔚 Final Thoughts

- Use **SQL** for structured, relational data where **integrity** and **complex queries** matter.
- Use **NoSQL** for **flexibility**, **horizontal scaling**, and **handling massive or semi-structured data**.
- NoSQL prioritizes **performance and availability**, while SQL prioritizes **consistency and integrity**.

[rhythmjayee]

TBH I did not find any video on YT this detailed.
Thanks🙇‍♂

[motivation_hubPJ]

Thanks for the video really nice explaination

[praveenkrdas]

Great work Shrayansh.Keep Posting such an Informational videos like these 😍😍🤩🤩🥰🥰