MongoDB

MongoDB stores JSON-like documents in collections. There is no fixed schema: documents in one collection may have different fields, and the structure is whatever the application writes.

The case for it is genuine in a narrow band, and the case against it is that the band is narrower than its adoption suggests.

The flexibility is real and relocated, not removed

“Schemaless” means the database does not enforce a schema. It does not mean there is no schema — the application still expects particular fields with particular types, and every piece of code reading a document encodes assumptions about its shape.

So the schema moves from one place where it is enforced to many places where it is not. Adding a field is easy; the difficulty arrives later, when a collection contains documents written by three versions of the application and every reader must handle all three shapes. Nothing tells you which shapes exist, and there is no equivalent of a migration history to consult.

This is the cost, and it is deferred, which is why it is easy to underestimate. Early development genuinely is faster.

Where it actually fits

Documents that are genuinely documents — nested, variably shaped, and always accessed as a unit. Scraped content, event payloads, and configuration blobs fit this well, and normalising them into relational tables is real work for no benefit.

Write-heavy workloads with simple access patterns, where horizontal sharding is built in rather than added on.

Where it fits badly is data with relationships. No joins in the relational sense means either denormalising — accepting duplication and the update anomalies that follow — or performing joins in the application, which is slower and more error-prone than the database doing it. If the data has entities referring to each other, that is a relational shape, and using a document store for it means reimplementing the relational parts by hand.

The middle path

PostgreSQL’s jsonb covers much of the useful ground: schemaless columns with indexing, inside a database that still enforces constraints on everything else. For a mostly-relational model with some genuinely variable fields — which describes most applications that reach for Mongo — this is usually the better structure.

Modern MongoDB supports schema validation and multi-document transactions, which closes some of the gap and is worth enabling. Both are opt-in, and a collection created without validation has none.

See also: PostgreSQL, schemas, models, and Redis for a different non-relational role.