Chapter 3 — MongoDB Fundamentals

The why

MongoDB is the most popular NoSQL database — and the most misunderstood. Used correctly, it's a rocket ship for rapid development with flexible schemas. Used incorrectly, it's a data corruption machine with no guardrails. This chapter teaches you which side of the line you're on.

Core concepts

The MongoDB vocabulary

MongoDB uses different words for the same concepts. Translating between SQL and MongoDB is the first thing to master:

Documents and BSON

A MongoDB document is JSON-like, but stored as BSON (Binary JSON) — a binary format that extends JSON with additional types:

{
  "_id": ObjectId("6645a1b2c3d4e5f6a7b8c9d0"),
  "name": "Alice Chen",
  "email": "alice@example.com",
  "age": 34,
  "joinedAt": ISODate(

BSON adds types JSON lacks: Date, ObjectId, Binary, Decimal128 (exact decimals for money), Timestamp, Long (64-bit integer). When you use MongoDB from Node.js, the driver handles BSON ↔ JavaScript conversion automatically.

Embedded documents vs references

The single most important design decision in MongoDB. Do you embed child data inside the parent document, or store it separately with a reference?

// EMBEDDING — comments live inside the post
// Best when: comments are always accessed with the post, max ~100 per post
{
  _id: ObjectId("..."),
  title: "My Post",
  body: "...",
  comments: [
    { user: "alice", text:

The aggregation pipeline

MongoDB's aggregation pipeline is the NoSQL equivalent of SQL — but instead of writing a statement, you build a pipeline of stages. Each stage transforms documents and passes them to the next stage.

// SQL:
// SELECT status, COUNT(*) as count, AVG(total) as avgTotal
// FROM orders
// WHERE createdAt > '2025-01-01'
// GROUP BY status
// HAVING COUNT(*) > 5
// ORDER BY count DESC
 
// MongoDB aggregation pipeline:
db.orders.aggregate([
  //

Key aggregation stages:

Write and read concerns

MongoDB lets you trade consistency for speed. You set this per operation:

Write concern — how many nodes must confirm a write before returning:

// Fast but risky: write to primary only, don't wait for journal
db.orders.insertOne(doc, { writeConcern: { w: 1, j: false } });
 
// Safe: write must reach primary + 2 secondaries, journaled
db.orders.insertOne(doc

• w: 1 — primary only (fast, data lost if primary crashes before replication)
• w: "majority" — primary + enough secondaries to have majority (safe, slower)
• j: true — write must be in the journal on disk (survives power loss)

Read concern — what data state can be read:

• local — read whatever is on this node, even uncommitted data (fast, might read rolled-back data)
• majority — only read data confirmed by a majority of nodes (safe, might be slightly stale)
• linearizable — guarantee that you read the absolute latest write (slowest, one-node-at-a-time)

For most web apps: w: "majority" on writes, readConcern: "local" on reads from primary, readConcern: "majority" on reads from secondaries.

Real-world example: How Uber uses MongoDB

Uber's architecture is a fascinating mix. They use PostgreSQL for high-consistency data (payments, trips, accounting) and MongoDB for high-flexibility data:

1. Rider preferences — every rider has custom settings. Some want "quiet mode," some want preferred music, some want specific pickup instructions. The schema varies wildly per city, per rider type. MongoDB's flexible schema is perfect here.

2. City configurations — Uber operates in 10,000+ cities, each with different pricing rules, surge multipliers, service types (UberX, Black, Pool). One document per city, each with a different shape. PostgreSQL would need hundreds of nullable columns or an EAV pattern (entity-attribute-value — slow and painful to query).

3. Real-time event logging — every ride generates hundreds of events (driver accepted, rider picked up, GPS pings, drop-off). MongoDB's high write throughput handles millions of inserts per second across sharded clusters.

Uber moved away from MongoDB for their core trip data in 2016 (to a custom schemaless datastore built on MySQL), which teaches an important lesson: MongoDB excels at flexible, read-heavy, or write-heavy workloads with variable schema. It's weaker at highly relational data that requires complex transactions across multiple entities.

Common mistakes

Production notes

• Enable authentication. MongoDB's default config has no auth. Anyone on the network can read and write everything. Always enable security.authorization: enabled.
• Use replica sets, even in development. Many features (transactions, change streams) require a replica set. Run a single-node replica set locally.
• Monitor the oplog. The oplog is MongoDB's replication log. If it fills up faster than secondaries can read it, replication halts. Size it based on your write volume.
• Connection pooling. MongoDB's Node.js driver pools connections by default. Set maxPoolSize — usually 100 per application instance is enough.
• Atlas is almost always worth it. MongoDB Atlas (the managed service) handles replication, backups, monitoring, and upgrades. Self-hosting MongoDB at scale is difficult.

Performance notes

• Covered queries are the fastest. If an index contains all the fields asked for in the query, MongoDB reads only from the index, never touching the documents. Use .project() to limit returned fields.
• $lookup is slow by design. It doesn't use indexes on the joined collection the way SQL JOINs do. Restructure your schema to avoid frequent $lookup usage.
• Aggregation pipeline memory limit is 100 MB. Larger aggregations must use allowDiskUse: true, which is dramatically slower. Add $match and $limit stages early to keep the working set small.
• Indexes in MongoDB are B-trees, same as PostgreSQL. The same rules apply: index foreign keys, index fields in $match, use compound indexes for multi-field queries.

Security notes

• Always enable TLS. MongoDB connections are plaintext by default. Anyone on the network can sniff queries and results.
• Use SCRAM authentication, never the legacy MongoDB-CR. Rotate credentials regularly.
• Enable IP whitelisting (Atlas makes this easy). Only your application servers should connect to the database.
• Watch for NoSQL injection. MongoDB queries are JSON, not strings — but $where (JavaScript execution in queries) exists and is dangerous. Never build $where clauses from user input.

// DANGEROUS: user input goes directly into $where
db.users.find({ $where: `this.email == '${req.body.email}'` });
// Attacker input: '; while(true){}; //' → infinite loop on the database
 
// SAFE: use $eq or other operators
db.users

Exercises

Beginner

1. Install MongoDB locally (or use Atlas free tier). Create a blog database with posts and comments collections. Insert 3 posts and 5 comments (referenced, not embedded). Write a query with $lookup to get each post with its comments.
2. Create an index on comments.postId. Use .explain("executionStats") to compare query performance with and without the index.

Intermediate

1. Build an aggregation pipeline that calculates the average comment count per post, grouped by the month the post was created. Use $group, $lookup, $group again, and $sort.
2. Model a social media "user profile" with embedded settings, embedded address, but referenced posts and referenced followers. Explain each choice.

Advanced

1. Set up a 3-node MongoDB replica set using Docker Compose. Test failover: write to the primary, kill the primary container, verify that a secondary becomes primary and your data is intact.
2. Implement Change Streams to build a real-time notification system: watch the messages collection for inserts and push new messages to connected WebSocket clients.

Interview questions

Beginner

1. What is a document in MongoDB? How does it differ from a row in PostgreSQL? A document is a BSON (Binary JSON) object stored in a collection. Unlike a row, documents in the same collection can have different fields and structures. There's no enforced schema by default.

2. What is the _id field? Every MongoDB document has an _id field that serves as the primary key. If not provided, MongoDB auto-generates an ObjectId — a 12-byte value encoding timestamp, machine ID, process ID, and a counter, ensuring global uniqueness.

3. What's the difference between find() and aggregate()? find() is for simple queries (filtering, sorting, limiting). aggregate() is for complex data transformations through a pipeline of stages: filtering, grouping, joining, reshaping.

Senior

4. When would you choose MongoDB over PostgreSQL, and when would you not? Choose MongoDB when: your data schema varies per document (user preferences, product catalogs with varied attributes), you need very high write throughput, or your data is naturally document-shaped (content management, event logs). Don't choose MongoDB when: your data is highly relational (ORDER BY user, products with categories), you need complex multi-table transactions frequently, or you need strong schema enforcement for regulatory compliance.

5. Explain how MongoDB replication works. MongoDB uses a replica set — one primary and multiple secondaries. All writes go to the primary and are recorded in the oplog (a capped collection of operations). Secondaries continuously tail the oplog and apply operations asynchronously. If the primary fails, the remaining nodes hold an election to choose a new primary. A majority of voting nodes must be available for an election to succeed.

6. What is the 16 MB document limit and how do you work around it? MongoDB documents cannot exceed 16 MB (BSON size limit inherited from v1). For large data: use GridFS (splits files into 255 KB chunks), use referenced documents instead of embedding large arrays, or store metadata in MongoDB and the actual data in object storage (S3) with a URL reference.

Summary

MongoDB is a document database that excels at flexible-schema workloads, rapid prototyping, and high write throughput. Its aggregation pipeline is the NoSQL equivalent of SQL. The key design decisions are: embed vs reference, where to place $match stages, and what write/read concern levels to use. MongoDB and PostgreSQL are complementary — many production systems use both. Use MongoDB where the schema is variable; use PostgreSQL where the data is relational.

Quick recall

• Document = JSON-like BSON. Collection = group of documents. Database = group of collections.
• Embed child data when it's small, bounded, and always accessed with the parent. Reference when it's large, unbounded, or independently queried.
• Aggregation pipeline: $match → $group → $sort → $project. Always push $match and $limit as early as possible.
• Write concern w: "majority" for safety. Read concern "local" for speed, "majority" for consistency.
• MongoDB has ACID transactions since 4.0 — but they're slower than single-document writes.
• The 16 MB document limit is real. Embed only what stays under it.

Quiz

1. What does BSON add that JSON doesn't have? Date, ObjectId, Binary, Decimal128, Long (64-bit integer), Timestamp types.
2. A post has 500,000 comments. Should you embed or reference them? Reference. The post document would exceed 16 MB and every comment write would rewrite the entire post.
3. What happens if you put $sort before $match in an aggregation pipeline? MongoDB sorts all documents in the collection before filtering — extremely slow and memory-intensive. Always put $match first.
4. What does writeConcern: { w: "majority" } guarantee? The write has been acknowledged by a majority of replica set members, meaning it will survive a primary failure.
5. What MongoDB feature requires a replica set? Transactions (multi-document ACID), Change Streams (real-time data watching).
6. Name a company that uses MongoDB and for what. Uber — rider preferences and city configurations (variable schema). Adobe — content management. eBay — product catalog with varied attributes.
7. How do you prevent NoSQL injection in MongoDB? Avoid $where with user input. Use typed query operators ($eq, $gt) instead of constructing query strings. Validate and sanitize all user inputs.