MongoDB — Flexible Document Database

Before you start: basic familiarity with what a database is for (storing and retrieving data reliably) is assumed, but no prior MongoDB or NoSQL experience is needed. If you've done the SQL Mastery page, the comparisons below will click faster, but it isn't required — this page explains the document model from scratch either way.

A document database stores each record as a single self-contained unit (a document — essentially one JSON object) rather than splitting it across multiple linked tables. MongoDB is the most widely used document database: it stores data as JSON-like documents instead of rows and tables, and — unlike a traditional table, where every row must have the same columns — each document can have a different structure. That flexibility is what makes it a good fit for evolving schemas, nested data, and applications that don't fit neatly into the relational (table-based) model.

Document vs Row

SQL Row (rigid — all rows must have same columns):
| id | name  | email           | phone       |
| 1  | Alice | alice@email.com | +91-9876543 |
| 2  | Bob   | bob@email.com   | NULL        |

MongoDB Document (flexible — each document can differ):
{
  "_id": "507f1f77bcf86cd799439011",
  "name": "Alice",
  "email": "alice@example.com",
  "phone": "+91-9876543",
  "address": {                     ← Nested object (no JOIN needed)
    "city": "Bangalore",
    "state": "Karnataka"
  },
  "tags": ["admin", "developer"],  ← Arrays built-in
  "preferences": {
    "theme": "dark",
    "notifications": true
  }
}

When to Use MongoDB

Good fit:

Not a good fit:

A note on financial transactions: it's a common but outdated claim that MongoDB "can't do ACID" and is therefore unsuitable for financial data — MongoDB has supported multi-document ACID transactions since version 4.0 (2018, single replica set) and 4.2 (sharded clusters). Financial systems still often lean toward relational databases, but the real reasons are usually schema rigidity/constraints being a good fit for regulated data, mature reporting/JOIN tooling, and organizational familiarity — not a technical ACID limitation that no longer exists. MongoDB's own material even recommends single-document atomicity (via schema design) over multi-document transactions where possible, due to the performance cost of the latter — but "not possible at all" is simply inaccurate.

The Aggregation Pipeline

MongoDB's most powerful feature for analysis is the aggregation pipeline: instead of one query trying to do everything at once, you chain together simple stages, each one taking the previous stage's output and transforming it further — the same idea as piping commands together in a shell, but for documents. A typical pipeline for "revenue by city, from completed orders" looks like this:

Each stage is independently simple — the power comes from chaining them, the same way a handful of simple shell commands piped together can do something none of them could alone.

Quick Start

// Connect
const { MongoClient } = require('mongodb');
const client = new MongoClient('mongodb://localhost:27017');
await client.connect();
const db = client.db('myapp');
const users = db.collection('users');

// Insert
await users.insertOne({ name: 'Alice', email: 'alice@example.com', age: 30 });
await users.insertMany([
    { name: 'Bob', email: 'bob@example.com', age: 25 },
    { name: 'Charlie', email: 'charlie@example.com', age: 35 }
]);

// Find
const user = await users.findOne({ email: 'alice@example.com' });
const all = await users.find({ age: { $gte: 25 } }).toArray();

// Update
await users.updateOne({ email: 'alice@example.com' }, { $set: { age: 31 } });

// Delete
await users.deleteOne({ email: 'bob@example.com' });

More Aggregation Stages

// $bucket — histogram / range grouping
db.products.aggregate([
    { $bucket: {
        groupBy: "$price",
        boundaries: [0, 50, 100, 200, 500, 1000],
        default: "1000+",
        output: { count: { $sum: 1 }, products: { $push: "$name" } }
    }}
])

Computed Pattern — Pre-Calculate Aggregates

// Update stats on every write, avoid expensive aggregations on read
{
    _id: "product_123",
    name: "Laptop",
    stats: {
        totalReviews: 1523,
        averageRating: 4.3,
        ratingDistribution: { "5": 800, "4": 400, "3": 200, "2": 80, "1": 43 },
        lastUpdated: ISODate("...")
    }
}

Python with PyMongo

from pymongo import MongoClient, InsertOne, UpdateOne, DeleteOne
from pymongo.errors import DuplicateKeyError

client = MongoClient("mongodb://admin:password@localhost:27017")
db = client.myapp

try:
    result = db.users.insert_one({"email": "alice@example.com", "name": "Alice"})
    print(f"Inserted: {result.inserted_id}")
except DuplicateKeyError:
    print("Email already exists")

# Bulk operations — efficient for many writes at once
operations = [
    InsertOne({"email": "new@example.com", "name": "New User"}),
    UpdateOne({"email": "alice@example.com"}, {"$set": {"age": 31}}),
    DeleteOne({"email": "old@example.com"})
]
result = db.users.bulk_write(operations, ordered=False)

Interview Questions

What is the CAP theorem and where does MongoDB sit?

CAP theorem states a distributed system can guarantee at most two of three: Consistency, Availability, Partition tolerance. MongoDB prioritizes Consistency and Partition tolerance (CP). With default write concern w:1, a write is acknowledged when the primary confirms it — replicas may briefly lag. With w:majority, writes require acknowledgment from most replica set members, ensuring stronger consistency at the cost of slightly higher latency. MongoDB sacrifices some availability (during network partitions, the minority partition becomes read-only) to maintain consistency.

Explain the aggregation pipeline vs. MapReduce.

The aggregation pipeline processes documents through sequential stages — each stage transforms the data and passes it to the next. It's native, highly optimized, and runs entirely in the database engine. MapReduce in MongoDB uses JavaScript functions running in a separate interpreter — much slower, harder to debug, and effectively legacy at this point in favor of the aggregation pipeline. Always use the aggregation pipeline — the only historical reason MapReduce existed was for complex logic that pipeline stages couldn't express, and the aggregation pipeline's $function and $accumulator stages now cover those cases too.