In Elasticsearch, how do you choose between nested, a join field, and denormalization?

## Frame the decision as three measurements Every useful answer here comes from data, not taste. Measure, on real traffic: 1. **Fan-out** — children per parent: the median and, more importantly, the tail. Bounded at a handful, or unbounded and growing? 2. **Churn ratio** — child writes per parent write. Do children change with the parent, or independently and far more often? 3. **Query profile** — reads per second, latency budget, and which entity the result page actually shows. The third question is the one teams skip, and it usually settles the model on its own: **index the thing you want to return**. ## Denormalization is the default One document per entity to be returned, carrying whatever parent context the query needs. A search over order lines indexes one document per line, with the customer's region and the order date copied in. Every document is independent — index, update, delete in isolation. Queries are plain `bool` clauses with no special syntax, no cross-object matching, no expensive-query gate. Throughput scales with shard count. What you pay: storage for duplicated fields, and a fan-out re-index when a parent field that was copied changes. That second cost is the one to size honestly — if the customer's region changes for a customer with a million lines, that is a million updates, typically through `_update_by_query` on a background schedule. If parent fields are stable, the cost is near zero and denormalization wins outright. ## Nested: correlation with a bounded many-side Choose nested when three things are all true: the many-side is small and has a natural ceiling; it always changes at the same time as the parent; and the query must require several child fields to match the *same* entry while returning the parent. Product variants, garment sizes, a person's addresses. What you pay: each entry becomes a Lucene document, so physical document count multiplies, and because blocks are immutable and contiguous, changing one field rewrites the parent and every child. `index.mapping.nested_objects.limit` (default 10000) caps a single document's objects; hitting it is a signal to remodel, not to raise it. Sorting needs the `nested` sort option, aggregating needs a `nested` aggregation, and showing the matched entry needs `inner_hits`. The disqualifier is unbounded growth. An array that appends forever turns every write into a bigger rewrite; that model must change before it reaches production scale. ## Join field: independent children, at a price A `join` field buys precisely one property that neither other option offers: a child can be created, updated or deleted without rewriting its parent or its siblings. That matters when children vastly outnumber parents and change constantly while parents are stable. What you pay is broad. Children must be routed to the parent's shard, so an uneven fan-out concentrates a hot parent's children on one shard and skews the cluster. The join field maintains eagerly built global ordinals, so refreshes get more expensive as the index grows. Joining queries are markedly slower than the equivalent nested query and are classed as expensive queries, so a locked-down cluster may refuse them. An index may declare only one join field, a child has exactly one parent, and the relation cannot span indices. That bundle is affordable at moderate query rates and unaffordable at high ones. Parent-child is a write-optimised model paid for at read time; it is the exception, not the starting point. ## Application-side join Sometimes the honest answer is two queries: search the children, collect parent ids, fetch the parents with a single multi-get or a `terms` filter, and assemble in the service. It costs a round trip and some code, but it keeps both indices simple, works across indices, and never surprises anyone with cross-object matching or a shard-skew incident. For low-cardinality lookups it is frequently the cheapest option overall. ## Deciding, concretely - Bounded fan-out, children change with parent, need correlated matching, return the parent → **nested**. - Any fan-out, results are the child entity, parent fields stable → **denormalize**. - Huge fan-out, child churn far exceeds parent churn, read volume modest → **join field**. - Relation spans indices, or is needed only for display → **application-side join**. ## Governing it Write the rule down and enforce it in review, because these choices are expensive to reverse: every one of them requires a full reindex, and the query, sort, aggregation and highlighting code all change with the model. Two guardrails are cheap and effective: benchmark with production-shaped data before committing, comparing physical document count and documents rewritten per update; and make aliases-plus-reindex the standard migration path so a wrong choice is recoverable without downtime. Treat "we used nested because the JSON was nested" as the defect it is — the shape of the incoming JSON is not an argument for any of these three models.