DEV Community

Cover image for Week 10: Databases - The Real Backbone of Our Apps!
Nikhil Sharma
Nikhil Sharma

Posted on

Week 10: Databases - The Real Backbone of Our Apps!

#webdev #postgres #beginners #backend

This week, I went deeper into something that quietly run the entire show behind our apps - databases.

Honestly, this was one of those weeks where everything just clicked. The more I understood, the more things felt structured and “ohhh, so that's how it's done.” Let’s get right into it!

🗂️ Types of Databases

At the highest level, we can split databases into two big families:

1. SQL Databases (Relational)

These are structured, rigid, strict but all in a good way.

  • Data lives in tables
  • Tables have columns with fixed types
  • There are relationships between tables
  • Everything is based on a schema we define upfront
  • We interact using SQL (Structured Query Language)

Examples: PostgreSQL, MySQL, MariaDB, SQL Server

2. NoSQL Databases (Non-Relational)

These are way more flexible and relaxed with structure.

  • No fixed schema
  • Great for rapidly changing data
  • Designed for quick reads, massive scale
  • Data can be documents, key-value pairs, graphs, columns…

Examples: MongoDB, Redis, Cassandra, DynamoDB

Where MongoDB Fits

MongoDB is a NoSQL Document Database.

Instead of rows and columns, MongoDB stores data as documents that look like JSON.

A user record might look like this:

{
  "name": "Ayu",
  "age": 20,
  "hobbies": ["painting", "reading"]
}
Enter fullscreen mode Exit fullscreen mode

This is super flexible! We can add or remove fields anytime and get no schema alerts.

MongoDB Advantages

MongoDB does a bunch of things really well:

  • Schema flexibility - perfect for fast prototyping
  • Horizontal scaling - adding more servers is easier
  • Great for document-shaped data
  • Works naturally with JavaScript since it uses JSON-like syntax
  • High read performance when queries align with document structure

When we want speed and flexibility(say in a hackathon), MongoDB feels amazing.

But MongoDB Has Its Downsides Too

As we scale, we start to notice some cracks:

  • Relationships are painful Joining data across collections feels messy.
  • Data integrity isn’t guaranteed by default If we expect strict correctness → things get tricky.
  • Query patterns can degrade performance Indexing becomes super important and manually tuned.
  • Harder to enforce structure Which means bugs can slip into the data layer.

MongoDB is perfect until we need the kind of discipline that big systems demand.

🧠 Why Most Companies Still Prefer SQL

Across the industry, SQL remains the default, and once we dig into it, the reasons feel obvious.

SQL databases like Postgres give us:

  • Structure
  • Predictability
  • Reliability
  • Better Relationships
  • ACID guarantees
  • Rich querying capabilities

When correctness matters, SQL usually wins.

Say in payments, inventory, authentication, banking, analytics, logistics and so many more. Basically anything where one mistake can cause a lot of trouble, SQL wins.

Why SQL (especially Postgres) feels better for many use cases:

  • Every table has a schema → fewer “surprise bugs”
  • Strong JOIN support → complex relationships are easy
  • Transactions → either everything succeeds or nothing does
  • Indices, constraints, triggers → very mature tooling
  • Postgres-specific power-ups:
    • JSON support (best of both worlds)
    • Window functions
    • Full-text search
    • Extensions like pgvector, PostGIS

Postgres feels like that reliable friend who just never drops the ball.

⚠️ But SQL Has Some Cons Too

Nothing is perfect.

  • Schema changes can be heavy
  • Horizontal scaling is harder
  • Rigid structure might feel slow during rapid iteration
  • Requires more planning upfront

Still, for most of the systems we want to build, SQL’s strengths massively outweigh its weaknesses.

🐘 Our Choice This Week: PostgreSQL

So this week was all about Postgres, one of the most powerful SQL databases out there.

We focused on understanding:

  • How tables are created
  • How constraints keep our data safe
  • How relationships work using foreign keys
  • How SQL queries are structured
  • Why good database design matters

And since we’re building in the JavaScript ecosystem, we’ll be pairing Postgres with Prisma as our ORM but that’s a whole topic by itself, so that’s coming next week.

This week is pure SQL.

SQL Examples — With Intuition

▶ Creating a Table 

CREATE TABLE users (
  id SERIAL PRIMARY KEY,
  name TEXT NOT NULL,
  email TEXT UNIQUE NOT NULL
);
Enter fullscreen mode Exit fullscreen mode

What’s happening?

We’re designing a structure where:

  • id auto-increments
  • name must always exist
  • email must be unique
  • Postgres will now enforce these rules for us

This is the kind of discipline that NoSQL doesn’t enforce.

▶ Inserting Data 

INSERT INTO users (name, email)
VALUES ('Ayu', 'ayu@example.com');
Enter fullscreen mode Exit fullscreen mode

This just means:

“Put a new row into the users table with these values.”

SQL has a learning curve which could be slow in the beginning but, as is the case with everything, gets easier with practice.

▶ Querying Data 

SELECT * FROM users WHERE email = 'ayu@example.com';
Enter fullscreen mode Exit fullscreen mode

We’re pulling only the data that matters.

This precision is where SQL shines.

▶ Updating Data 

UPDATE users
SET name = 'Ayu'
WHERE id = 1;
Enter fullscreen mode Exit fullscreen mode

We’re telling Postgres:

  • “Find the row where id = 1”
  • “Change the name to Ayu”

▶ Deleting Data 

DELETE FROM users WHERE id = 1;
Enter fullscreen mode Exit fullscreen mode

Again - clean and readable(because our use-case is simple – SQL queries can get very complex, but an ORM helps simplify it further).

Wrapping Up

This week gave us a solid foundation in understanding why databases behave the way they do, and why SQL (especially Postgres) is still the king for most real-world applications. MongoDB is incredible for flexibility and fast-moving projects but SQL is unbeatable for consistency and correctness.

Next week, we’ll take all this knowledge and plug it into Prisma, making database interactions feel a LOT easier.

If you have any questions or feedback, make sure to comment and let me know!

I'll be back next week with more. Until then, stay consistent!

Top comments (2)

Collapse
 
leob profile image
leob • • Edited

Yeah, RDBMS (SQL) is the obvious choice for 90% of the apps and use cases - NoSQL is way overhyped, should really be selected for certain "niche" cases only - in most cases people choose it just to jump on the "hipster" bandwagon, and it turns out to be a poor choice ...

Collapse
 
nikhilsharma6 profile image
Nikhil Sharma •

Yeah, honestly, I totally agree. I followed the usual learning path that everyone recommends (NoSQL → SQL), so I documented it too. But in hindsight, I realise it’s almost unnecessary to dive deep into NoSQL unless you’re dealing with those specific niche use cases like you said.