MongoDB Data Modeling: Relationships, Duplication, Performance

Most data models do not break in development. They break under real workload pressure, which is why modern systems rarely fail because of the technology they chose and often fail because of the data model they built on it. For decades relational thinking shaped how engineers approached persistence: normalise everything, remove duplication, join later. It worked in a world of megabytes, batch jobs and predictable workloads. That world is gone. We now design for millions of users, petabytes of data, real-time APIs and AI-driven workloads, and the modelling discipline has to follow. This piece is about what that shift looks like in practice: the actual modelling process for MongoDB, how to answer the classic objections about joins and duplication, and where duplication is smart rather than dangerous.

Workloads, not tables

Traditional modelling starts from tables. MongoDB modelling starts from workloads, and the principle underneath it is short: data that is used together should live together. Relational thinking optimises for storage elegance; document thinking optimises for runtime behaviour, through embedding, referencing and a schema flexible enough to follow the application. In distributed systems, runtime wins.

So before touching any schema, ask the questions that drive the model. What are the main queries? What is the read/write ratio? What latency is required? What is the growth curve? Is this a write-heavy system, a read-heavy one, a low-latency one, a very large one, or one where simplicity matters more than any of those? None of this is academic. If you serve forty million product reads a day, optimising reads is mandatory and normalisation alone will not save you.

The next step, and the most underrated, is to classify the entities. Strong entities are the objects your queries return; they are the natural collection candidates. Lookup entities are small, slow-changing reference data, and can usually be duplicated safely. Weak entities do not exist on their own and are usually embedded. Associative entities, the ones that resolve many-to-many relationships in a relational schema, are often unnecessary in a document model. The classification alone already tells you where embedding will shine.

Embed or reference

This is where relational veterans get nervous, and the eternal question is “should I embed or reference?”. The answer is engineering, not dogma, and it comes from five questions. Are the data queried together? Are they updated together? Is the cardinality bounded? Will the document grow without limit? Can the child exist independently?

Embed when data is read together, cardinality is bounded, the child has no independent life, updates happen together and low latency is critical. The classic case is a customer with an address: embedding removes a join and simplifies the model. Reference when cardinality is very high, child entities are shared, updates happen independently, the document size would explode or the data has its own lifecycle. Orders referencing customers is the classic case on this side. Same methodology, two different outcomes, because the workloads are different.

“But what about joins?”

This is the first reflex from relational purists, and the honest answer is that MongoDB does support joins, through aggregation lookups. The real question is different: should your hot path need them? The Extended Reference pattern exists precisely because too many joins on read operations hurt performance, and its solution is pragmatic. Copy the few fields you need for the most common reads into the document that reads them. Not everything, only what matters. Surgical denormalisation, with faster reads and fewer lookups in exchange for a small amount of controlled duplication. That one pattern settles a surprising share of NoSQL debates.

“Duplication is dangerous”

The most emotional objection, and the most misunderstood, because duplication is not binary. It has types. Immutable data never changes and is a perfect candidate for copying. Temporal data is data where the value at a specific moment matters more than the latest value, the price on an invoice rather than the price in the catalogue, so duplication is not a risk but the requirement. Data that is very sensitive to staleness needs coordinated updates. Data that is not very sensitive to staleness can simply be refreshed periodically. In real projects this classification is pure gold, because it turns a theological argument into four engineering cases.

The trade-off should be stated plainly. Controlled duplication buys performance, scalability, lower cost, resilience and predictability; it costs the possibility of inconsistency, operational overhead and business risk if misused. In high-scale systems performance and predictability usually dominate. The skill is controlled duplication, not blind normalisation.

Patterns only when needed

Schema design patterns are powerful, but they are not decoration, and the guidance in MongoDB’s own design process is explicit: use them only if needed, because schemas do not have to be complex. This is where senior architects distinguish themselves, by leaving patterns out. Two are worth knowing by heart. The Computed pattern precomputes and stores the result of an expensive calculation that would otherwise be repeated on every read, trading possible staleness for faster reads and lower CPU; in read-heavy platforms it is often decisive. The Extended Reference pattern, already met above, embeds only the frequently accessed fields of a related entity to avoid joins on the hot path.

Validate with telemetry, not opinions

Architecture debates are cheap; metrics are the truth. Use explain plans, check that indexes are actually used, collect API telemetry and watch latency percentiles rather than averages. A simple rule falls out of the numbers: if latency is above target, optimise for performance; if latency is below target, optimise for simplicity. That is production wisdom, and it is the opposite of designing for an imagined scale.

Let me be precise about the claim, because MongoDB is not universally better. In modern workloads the document model has structural advantages: fewer joins on hot paths, which reduces latency variability; a natural fit for hierarchical data, since JSON maps directly to documents; better horizontal scalability, because related data can be co-located; faster feature evolution, thanks to a flexible schema and versioning. The document model flips the traditional relationship between application and data model, and in distributed architectures that inversion is powerful. Relational design optimises for theoretical purity, document design for system behaviour under load. In small systems both work. At scale, physics enters the room: network hops matter, join fan-out matters, hot paths matter, which is why modern high-volume platforms adopt document patterns even when relational systems remain in the stack.

Good MongoDB modelling is not about embedding everything. It is about understanding the workload first, classifying entities correctly, embedding with discipline, duplicating with intent and measuring continuously. Done properly, the document model does not create chaos. It creates predictable, scalable systems that match how applications actually behave.