MongoDB: When NoSQL Makes More Sense Than SQL

1. Problem: heterogeneous data structures

• SQL requires defining a fixed schema up front (each table has a predefined set of columns and data types).
• Difficult example to handle with SQL: e-commerce product catalogs, where each product category possesses distinct attributes (T-shirts have size/color, laptops have ram/cpu, books have author/isbn).
• 2 approaches to handle this in SQL, both rather cumbersome:
  1. A shared products table + separate sub-tables for each category (clothing_attributes, laptop_attributes...), where adding a new product category requires creating a new table and running DB migrations.
  2. A JSON/JSONB column storing flexible attributes, which avoids creating new tables but sacrifices SQL's strict data type validation for that specific payload.

2. MongoDB (document DB): flexible schema

• Each record is an independent "document" that freely defines its own structure without requiring a rigid schema:

{ name: "T-shirt", price: 150000, size: "M", color: "red" }
{ name: "Laptop X", price: 20000000, ram: "16GB", cpu: "i7" }

• The 2 documents above do not need identical schemas to reside within the same collection.

3. Trade-off: no automatic data type validation

• MongoDB (by default) does not prevent accidentally storing inconsistent data types for the same field (for example, price: "150000" as a string in one record, and price: 150000 as a number in another), unlike an SQL INT column that strictly rejects string insertions.
• Consequence: application-level validation (zod/class-validator covered in Phase 2) becomes significantly more crucial when working with MongoDB due to the lack of a DB-level safety net.

4. MongoDB is weaker than SQL for complex relational data

• MongoDB provides $lookup (the equivalent of a JOIN), but it is slower and less intuitive than SQL, as it was not architected for multi-directional, highly relational data.
• If your domain model requires extensive relational links across entities and multi-table transactions to guarantee strong consistency (for example, banking transactions, or orders-customers-products-order_items), SQL remains the superior choice.

5. Decision criteria: SQL vs. MongoDB

• Choose SQL when: data has a uniform structure across records of the same entity type, AND features complex relationships requiring JOINs and cross-table transactions to maintain strict consistency.
• Choose MongoDB when: data naturally exhibits heterogeneous structures across records (diverse product types, event logs with varying payloads per event type, flexible CMS content), AND has minimal complex cross-entity relationships.
• Important note: "write-heavy" by itself is not the primary reason to choose MongoDB. SQL engines (PostgreSQL/MySQL) handle write-heavy workloads exceptionally well when properly architected (balancing index overhead against write throughput, as covered in the index section). The deciding factors are data structure polymorphism and relationship complexity, not write volume.