Databases
MongoDB
MongoDB stores data as BSON (a binary form of JSON) documents grouped into collections, with no schema enforced by the database itself by default. Related data is typically embedded inside a document rather than joined across separate tables, and it's queried through MongoDB's own query language and drivers rather than SQL.
Why it matters
- It fits naturally nested or variable-shaped data well
- A product catalog where attributes differ wildly by category, or an event log where each event type carries different fields, maps more directly onto documents than onto a fixed set of relational tables.
- It's popular in the Node.js and JavaScript ecosystem
- Working with JSON-shaped documents in a JavaScript backend avoids some of the translation between rows and objects that a relational database requires.
- Horizontal scaling is a documented, first-class feature
- Sharding — splitting a collection across multiple servers — is built into MongoDB's own tooling rather than being an operational add-on bolted on afterward.
A document and a query
A document is inserted and queried using the driver's own methods rather than a separate query language written as text.
db.orders.insertOne({
customerId: 42,
status: "pending",
items: [{ sku: "ABC-1", qty: 2 }]
});
db.orders.find({ status: "pending" }).sort({ _id: -1 }).limit(10);Embedding vs referencing
The core modeling decision in MongoDB replaces the relational idea of a join: embed related data directly inside a document when it's usually read together and won't grow without bound, or store a reference (an ID) and query it separately when the data is shared across many documents or grows unbounded, like every comment ever posted on a popular post.
Schema validation without a fixed schema
Nothing stops two documents in the same collection from having different shapes by default, which is flexible early on but can let a document's structure drift inconsistently as an application evolves. MongoDB supports optional schema validation rules that can enforce a consistent shape when a team wants that guarantee back, without giving up the flexibility for fields that genuinely need it.
Mistakes people make here
- Modeling MongoDB exactly like relational tables
- Splitting data into many small collections joined with $lookup at query time gives up the main advantage of a document database — fetching one related, self-contained record in a single read — while still not getting a relational engine's enforced integrity in return.
- Embedding data that grows without bound
- Nesting every comment ever posted inside the document it belongs to eventually hits MongoDB's per-document size limit and makes that document slow to load and update long before that limit is reached.
- Skipping schema validation entirely
- Without any validation, document shape can drift inconsistently across the application's lifetime as fields are added, renamed, or dropped in some code paths but not others, and nothing in the database catches the inconsistency.
- Not indexing fields used in frequent queries
- MongoDB won't necessarily surface a slow, unindexed query the way a relational planner's warning might — a query that scans an entire collection can run for a long time with no obvious signal until it's noticed in production.
Strengths and trade-offs
Where it is strong
- Document shape maps naturally onto how many applications already think in JSON, particularly JavaScript and Node.js backends.
- Flexible schema makes early, fast-changing projects quicker to iterate on than a relational schema with migrations for every change.
- Embedding related data in one document avoids joins entirely for the read patterns it fits.
- Sharding for horizontal scale is a built-in, documented feature rather than a separate operational project.
The trade-offs
- There's no enforced foreign key, so referential integrity across collections is entirely the application's responsibility, not the database's.
- Multi-document transactions exist but are heavier and used more sparingly than transactions are in a relational database's day-to-day workflow.
- Flexible schema also means nothing stops document shape from drifting unless the team is disciplined or turns on schema validation.
- Denormalized, embedded data means the same fact can exist in multiple places and go stale if an update misses one of them.
Who needs this
A good fit for teams with genuinely variable-shaped or deeply nested data and read patterns favoring whole-document fetches; a less clear-cut choice for data that's naturally tabular with real relational integrity needs.
Questions about mongodb
- Does MongoDB support transactions?
- Yes, multi-document ACID transactions have been supported since version 4.0, but they're used more sparingly than in a relational database, since the document model is designed to need them less often for typical operations.
- When should I embed data versus reference it?
- Embed data that's usually read together and won't grow without bound; reference data (store an ID and query separately) when it's shared across many documents or could grow indefinitely, like comments on a popular post.
- Is MongoDB truly schema-less?
- There's no schema enforced by the database by default, but a real application still needs a consistent document shape in practice — optional schema validation can enforce one when that consistency matters.
- Is MongoDB a good fit for financial or accounting data?
- Usually not the first choice — that kind of data typically needs strict relational integrity and multi-record transactional consistency that a relational database is built to enforce more directly.