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.
Data and databases
MongoDB used deliberately.
Document storage used deliberately: when the shape of the data really is irregular, how we model it, and what we do about the consistency questions it raises.
The working rules we hold to
-
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 no one 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.
Discuss the next step
Tell us what you want to build or improve. We reply with a plan, an indicative budget and a start date.