Relational databases normalize data into tables with JOINs; MongoDB often embeds related data in one document or uses $lookup when needed. Neither is always better—pick by access patterns.
Side-by-side mental model
| SQL | MongoDB |
|---|---|
| Table | Collection |
| Row | Document |
| Column | Field |
| JOIN | Embed or $lookup |
| PRIMARY KEY | _id |
When documents often win
- Product catalogs with varying attributes per SKU
- User profiles with nested settings
- High-volume append-only events (with TTL indexes)
When SQL often wins
- Complex reports across many normalized entities
- Strict referential integrity across dozens of tables
- Heavy multi-table transactions (still possible in MongoDB 4.0+ but less idiomatic)
Postgres JSONB blurs the line for semi-structured fields inside relational models.
Important interview questions and answers
- Q: N+1 problem in Mongo?
A: Fetching many documents then querying related collections per doc—batch with aggregation or embed wisely. - Q: Can MongoDB do JOINs?
A: Yes via $lookup in aggregation—not the default modeling style.
Self-check
- What MongoDB stage approximates SQL JOIN?
- Name one workload better suited to embedded documents.
Tip: Draw your access patterns before choosing embed vs reference.
Interview prep
- Collection vs table?
- Collection holds documents with flexible fields; table enforces uniform columns.
- JOIN equivalent?
- $lookup in aggregation—or embed related data.