Curly Brackets LogoCurly Brackets
Intro to databases: SQL vs NoSQL for junior developers

Intro to databases: SQL vs NoSQL for junior developers

2025-12-12
DatabasesSQLNoSQL

As a junior developer, you will eventually face the inevitable question when starting a new project: "Where do we put the data?"

For decades, the answer was almost always a Relational Database (SQL). But the rise of big data, rapid prototyping, and massive scaling introduced Non-Relational Databases (NoSQL) as a popular alternative.

In this guide, we will break down the differences, compare the terminology, and give you a simple framework to decide which one to use.

The Two Big Players

1. Relational Databases (SQL)

SQL stands for Structured Query Language. These databases have been around since the 1970s and are incredibly mature. Think of them like a collection of spreadsheets that talk to each other.

  • Structure: Strict. You must define your schema (columns and data types) before adding data.
  • Examples: PostgreSQL, MySQL, SQLite, Microsoft SQL Server.

2. Non-Relational Databases (NoSQL)

NoSQL encompasses a variety of database technologies developed in response to the rigid nature of SQL. They are designed for flexibility and scale.

  • Structure: Flexible. You can often insert data without defining a schema first.
  • Examples: MongoDB (Document), Redis (Key-Value), Cassandra (Wide-column).

The Vocabulary Shift: Tables vs. Collections

If you are coming from a background of Excel or basic SQL, the shift to NoSQL changes the vocabulary. Here is your cheat sheet:

Concept SQL Term NoSQL (Document) Term
Container Table Collection
Data Item Row Document
Data Point Column Field

Visualizing the Data: Rows vs. Documents

Let's imagine we are building a blog. Here is how we might store a user.

The SQL Way

In SQL, we need a defined structure. If a user has multiple hobbies, we typically cannot just stuff them into a single cell; we would ideally create a separate table for hobbies and link them (normalize the data).

/* Users Table */
+----+-------+-------------------+
| id | name  | email             |
+----+-------+-------------------+
| 1  | Alice | alice@example.com |
+----+-------+-------------------+

To get this data, you write a query:

SELECT * FROM Users WHERE id = 1;

The NoSQL Way

In a Document store like MongoDB, data looks like JSON. We can nest arrays (like hobbies) directly inside the user's document. No separate table required.

{
  "_id": "507f1f77bcf86cd799439011",
  "name": "Alice",
  "email": "alice@example.com",
  "hobbies": ["coding", "hiking", "gaming"]
}

To get this data using a JavaScript-based syntax (common in MongoDB):

db.users.find({ name: "Alice" })

The Trade-off: ACID vs. Eventual Consistency

Why not just use NoSQL for everything? It looks easier, right? The trade-off usually comes down to reliability versus speed/scale.

ACID (SQL)

SQL databases prioritize ACID compliance (Atomicity, Consistency, Isolation, Durability).

  • Scenario: You are transferring money from Account A to Account B.
  • Requirement: If the power goes out after money leaves Account A but before it hits Account B, the entire transaction must fail. SQL guarantees this.

Eventual Consistency (NoSQL)

Many NoSQL databases prioritize high availability and speed over immediate consistency.

  • Scenario: You post a photo on Instagram.
  • Requirement: If your friend sees the photo 2 seconds later than you do, it's not a disaster. As long as the data eventually propagates to all servers, it is acceptable.

Decision Framework: Which should you choose?

As a junior dev, you can use this simple heuristic to decide:

Choose SQL if:

  1. Relationships are complex: Your data has many connections (e.g., Users buy Products which belong to Categories).
  2. Data integrity is critical: Financial apps, inventory management, or healthcare data.
  3. The data structure is stable: You know exactly what columns you need and they won't change often.

Choose NoSQL if:

  1. Data structure is evolving: You are prototyping and fields might change daily.
  2. Unstructured data: You are storing logs, social media feeds, or IoT sensor data.
  3. Read speed and scale are priority: You need to handle millions of requests with low latency and don't require strict relationships.

Conclusion

Neither SQL nor NoSQL is "better"—they are just different tools for different jobs.

  • Use SQL when you need structure and strict rules.
  • Use NoSQL when you need flexibility and speed.

Mastering the basics of both will make you a much more versatile engineer.