What is MongoDB? NoSQL vs Relational Databases

MongoDB is the “M” in MERN — the database that stores all of your application’s data. Unlike the relational databases you may have used before (MySQL, PostgreSQL, SQLite), MongoDB does not organise data into rigid tables with fixed columns and rows. Instead it stores data as flexible, JSON-like documents grouped into collections. This document model is a natural fit for JavaScript applications because the data format — essentially a JSON object — maps directly to the JavaScript objects you already work with in your code. In this lesson you will understand what MongoDB is, how it differs from relational databases, and why it is the standard database choice for the MERN stack.

Relational vs Document Databases #

Why MongoDB Fits the MERN Stack #

The MongoDB Data Model — A Blog Post Example #

// In a relational database, this blog post spans THREE tables:
// posts table:    post_id | title | body | author_id | created_at
// post_tags:      post_id | tag_id
// tags table:     tag_id  | name

// In MongoDB, it is ONE document:
{
  "_id":       "64a1f2b3c8e4d5f6a7b8c9d0",
  "title":     "Getting Started with MERN",
  "slug":      "getting-started-with-mern",
  "body":      "The MERN stack is a powerful combination...",
  "excerpt":   "A complete guide to building full-stack apps.",
  "author": {
    "_id":    "64a1f2b3c8e4d5f6a7b8c9d1",
    "name":   "Jane Smith",
    "avatar": "https://cdn.example.com/jane.jpg"
  },
  "tags":      ["mern", "javascript", "beginner"],
  "published": true,
  "featured":  false,
  "viewCount": 142,
  "createdAt": "2025-01-01T00:00:00.000Z",
  "updatedAt": "2025-01-15T10:30:00.000Z"
}
// The author is embedded — no JOIN needed to display a post with author info

MongoDB Architecture #

MongoDB Server (mongod process — localhost:27017 or Atlas cluster)
│
├── Database: blogdb
│   ├── Collection: posts        ← like a table, but schema-flexible
│   │   ├── Document: { _id, title, body, author, tags, ... }
│   │   ├── Document: { _id, title, body, author, tags, ... }
│   │   └── Document: { _id, title, body, ... }  ← can have extra fields
│   │
│   ├── Collection: users
│   │   └── Document: { _id, name, email, password, role, ... }
│   │
│   └── Collection: comments
│       └── Document: { _id, postId, author, body, createdAt }
│
└── Database: admin              ← MongoDB system database (do not modify)

MongoDB vs MySQL — Blog Post Query #

── MySQL: Get a post with author and tags ────────────────────────────────────
SELECT p.*, u.name, u.avatar, GROUP_CONCAT(t.name) AS tags
FROM posts p
JOIN users u ON p.author_id = u.id
LEFT JOIN post_tags pt ON p.id = pt.post_id
LEFT JOIN tags t ON pt.tag_id = t.id
WHERE p.slug = 'getting-started-with-mern'
GROUP BY p.id;

── MongoDB (Mongoose): Get the same post ─────────────────────────────────────
await Post.findOne({ slug: 'getting-started-with-mern' })
  .populate('author', 'name avatar');
// Tags are already embedded in the document — no JOIN needed

Common Mistakes #

Mistake 1 — Choosing MongoDB for every project regardless of data shape #

❌ Wrong — using MongoDB for data that is fundamentally relational:

Accounting software with double-entry bookkeeping, complex multi-table constraints,
and strict ACID requirements across dozens of related records
→ A relational database (PostgreSQL) is a better fit here

✅ Correct — evaluate the data shape first. MongoDB is ideal for documents (blog posts, products, user profiles, activity logs). Relational databases are ideal for deeply interconnected, highly normalised data with complex integrity constraints.

Mistake 2 — Ignoring Mongoose schemas because MongoDB is “schemaless” #

❌ Wrong — writing directly to MongoDB without any schema enforcement:

// Without schema — anything goes
db.collection('posts').insertOne({ title: 123, random_field: true });
// Now your posts collection has inconsistent documents

✅ Correct — always define a Mongoose schema. MongoDB’s flexibility is for the database layer — your application layer should always enforce structure.

Mistake 3 — Storing ObjectIds as strings in references #

❌ Wrong — storing another document’s ID as a plain string:

{ author: "64a1f2b3c8e4d5f6a7b8c9d1" }  // plain string — populate() won't work

✅ Correct — use the ObjectId type for references so Mongoose’s populate() can resolve them:

author: { type: mongoose.Schema.Types.ObjectId, ref: 'User' }  // ✓

Quick Reference #