MongoDB is a good answer to a specific question: what if the records genuinely are not the same shape? Product catalogues with per-category attributes, event payloads from many sources, CMS content, integration data you do not control.
Model for the read
Document databases reward designing around how the data will be read. We embed what is always fetched together and reference what is not, and we accept a degree of duplication on purpose — with one place responsible for keeping the copies right.
Where teams get hurt
- Growing arrays without bound inside a document
- Rebuilding joins in application code across four collections
- Treating “schemaless” as “no schema”, instead of a schema enforced by validation rules
- Discovering after launch that a report needs a transaction across documents
We design against each of those explicitly, because all four are recoverable early and expensive later.
Consistency, stated plainly
Multi-document transactions exist and they cost throughput. Read and write concerns are chosen per operation with the trade written down, so nobody has to guess whether a given read can be stale.
Indexing and growth
Compound indexes matched to real query patterns, TTL indexes for data with a natural lifespan, and index size watched against memory. A collection whose working set no longer fits in RAM changes behaviour sharply, and that day should be predicted rather than experienced.
Honest positioning
If the data is relational, PostgreSQL will be simpler and cheaper to operate, and we will say so. MongoDB is a choice we make for a reason, not a default.