After this lesson, you will be able to: Compare document databases to relational databases honestly: when MongoDB is the right choice and when it isn't.
MongoDB is the most-used document database. Loved + hated. Useful for some shapes of data; the wrong tool for others. This subtrack teaches when to pick it.
This is a free introductory lesson. No purchase required.
Relational (Postgres, MySQL): structured tables with rows + columns; relationships via foreign keys; SQL queries. Document (MongoDB, DynamoDB, Firestore): collections of JSON-like documents; nested data first-class; query API per platform. Tradeoff: relational gives you schema enforcement + arbitrary joins; document gives you flexible schema + read-fast nested data.
Your data is genuinely document-shaped (CMS articles, product catalogs with varied attributes, IoT events). Read patterns are 'fetch one document + everything related' rather than 'join across many tables'. Schema must flex frequently (rapid prototypes, multi-tenant SaaS where each tenant differs). You need horizontal scale + Mongo Atlas managed service. Time-series data (Mongo has dedicated time-series collections).
Your data has lots of cross-relationships (joins), that's what SQL is for. You need strong ACID across multiple documents (Mongo has multi-document transactions but they're an afterthought). Reports + analytics, SQL is genuinely better at ad-hoc reporting. Reaching for MongoDB 'because NoSQL is modern', that's a vibes decision, not a technical one.
Two paths.
# Option 1: MongoDB Atlas (free tier, recommended for learning)# Sign up at mongodb.com/atlas → create a free M0 cluster → get connection string# Connect with `mongosh "mongodb+srv://..."`# Option 2: local MongoDB via Dockerdocker run --name mongo -p 27017:27017 -d mongo:7mongosh "mongodb://localhost:27017"# Once connected:test> show dbstest> use lastwritelastwrite> show collectionslastwrite> db.users.find()
Picking MongoDB without checking if data is actually document-shaped. Using MongoDB as a relational DB (lots of joins via $lookup → slow + complex). Skipping schema validation (your DB becomes garbage in 6 months). Storing money as Double instead of Decimal128 (floating-point precision bugs).