MongoDB is the best-known document database. Instead of tables with a fixed set of columns, you store documents: JSON-like objects that can nest and that don't all have to look the same. For developers who think in JavaScript objects, it can feel immediately natural. Let's see the model honestly, strengths and trade-offs both.
What it is
A MongoDB database has collections (loosely, the equivalent of tables), and a collection holds documents (the equivalent of rows). But a document is a rich JSON object, and two documents in the same collection can have different fields. There's no enforced schema by default.
// A document in the "products" collection
{
_id: ObjectId("..."),
name: "Mechanical Keyboard",
category: "Electronics",
price: 5499,
specs: { switches: "brown", layout: "75%" }, // nested object
tags: ["wireless", "rgb"] // array
}You query with a JavaScript-ish API rather than SQL:
// Find electronics under 2000, newest first, just two fields
db.products.find(
{ category: "Electronics", price: { $lt: 2000 } },
{ name: 1, price: 1 }
).sort({ createdAt: -1 });
// Aggregation pipeline (Mongo's answer to GROUP BY)
db.orders.aggregate([
{ $group: { _id: "$customerId", total: { $sum: "$amount" } } },
{ $sort: { total: -1 } }
]);What the document model buys you
Functional · what it does
- Flexible shape. Documents can vary and evolve without migrations, good for genuinely irregular data.
- Locality. Related data nested in one document is fetched in one read, no join needed.
- Maps to objects. A document often maps straight onto an app object, which feels natural.
Non-functional · what it must survive
- Easy to start. No schema to design up front; just insert objects.
- Horizontal scaling. Built-in sharding for spreading across many machines.
- Developer-friendly API. Query in a JS-like syntax rather than SQL.
The honest trade-offs
Most data is more relational than it first looks
The flexibility is real, but so is the catch: the moment your data has relationships (customers and their orders and the products in them), you either duplicate data across documents (and now updates must touch many copies) or you do the joins yourself in application code (which is slower and more error-prone than a database join). "No schema" also often means the schema just moved into your application code, undocumented. Many teams that started on MongoDB for speed later wished they'd modelled relationally. If your data is interconnected, that's a signal for Postgres, not Mongo.
When MongoDB genuinely fits
Reach for it when your data is naturally a pile of self-contained, varying documents that you mostly read and write whole: content/CMS items with wildly different fields, product catalogs with per-category attributes, event or activity logs, or rapid prototyping where the shape is still in flux. It's a poor fit when your data is highly relational or correctness-critical (money, inventory), where a relational database's joins and constraints are exactly what you want.
Postgres can do documents too
Worth remembering from the Postgres lesson: with JSONB columns, Postgres stores and queries JSON documents inside a relational table. So you can often get document flexibility and relational power in one system, rather than committing the whole database to the document model. That's why "we need MongoDB for flexibility" is frequently solvable with a JSONB column.
The one-liner
MongoDB stores flexible JSON documents in collections instead of rows in tables, which fits self-contained, varying data you read and write whole. It struggles when data is relational, because you end up duplicating or hand-joining. For interconnected or correctness-critical data, prefer relational, and remember Postgres's JSONB gives you documents without leaving the relational world.
Test yourself
Questions· say the answer out loud before you open it. If you can't, the chapter isn't done.
QWhat's the core difference between MongoDB and a relational database?+
MongoDB stores flexible JSON-like documents in collections, where documents can have different fields and nest objects and arrays, with no enforced schema by default. A relational database stores fixed-shape rows in tables with a defined schema and links tables by keys. You query Mongo with a JS-like API rather than SQL.
QWhat's the main downside of the document model?+
Relationships. When data is interconnected, you either duplicate it across documents (so updates must touch many copies) or join in application code (slower and more error-prone than a database join). 'No schema' also often just moves the schema, undocumented, into your app code.
QWhen does MongoDB genuinely fit, and when should you avoid it?+
It fits self-contained, varying documents you read and write whole: CMS content, per-category catalogs, event logs, rapid prototyping. Avoid it for highly relational or correctness-critical data like money and inventory, where relational joins and constraints are exactly what you need. And note Postgres JSONB offers documents without leaving relational.
Comments
Loading comments…