What does mapping a field as nested in Elasticsearch cost at index and update time?

## Document multiplication The cost model follows directly from the storage model. Each object in a nested array is indexed as its own Lucene document, written contiguously with the root in a block. A product with 200 variants is 201 Lucene documents. Ten million products with an average of 20 variants each is not 10 million documents but 210 million. The consequences are the ones you would expect from having ten or twenty times as many documents: larger segments, more postings, more merge work, more heap pressure during merges, and slower `forceMerge`. Shard sizing guidance that assumed one document per business entity becomes badly wrong. A reliable symptom: `_cat/indices` reports `docs.count` including nested documents, while a search's `hits.total` and the `_count` API report only root documents. An index that claims 210 million documents but returns 10 million on a `match_all` count is not broken — it has nested fields. ## Update amplification Lucene documents are immutable, and a nested block must remain contiguous and correctly ordered. So there is no such thing as updating one nested object. A partial update through `_update` reads the document's `_source`, applies the change, and re-indexes the entire document: the old block is marked deleted and a fresh block of root-plus-all-children is written. Appending one entry to a 500-entry array costs 501 deletions and 501 insertions. This is what makes nested wrong for high-churn children. A document whose array is appended to on every user action becomes a write amplifier: index throughput drops, deleted documents pile up until merges reclaim them, and disk usage inflates in the meantime. ## The limits Two index settings exist specifically to stop nested from destroying a cluster: - `index.mapping.nested_fields.limit` — the maximum number of distinct nested mappings an index may declare, default 50. It guards against a schema where dozens of fields are nested, each multiplying documents. - `index.mapping.nested_objects.limit` — the maximum number of nested objects a single document may contain, across all its nested fields, default 10000. Exceeding it rejects the indexing request rather than letting one pathological document explode a segment. Both are index settings, and both can be raised. Raising them is usually a signal to reconsider the model, not a fix: the limits exist because the underlying cost is real, and pushing them up moves the failure from a clean rejection to an out-of-memory event. ## Query and fetch cost Block join itself is efficient — finding the parent of a matching child is a forward scan within the block, not a term lookup. But the query still evaluates against many more documents than the root count suggests, and `inner_hits` adds per-hit fetch work that materialises child sources. Elasticsearch classes joining queries (nested and parent-child) among its *expensive queries*, which a cluster can disable wholesale with the `search.allow_expensive_queries` setting; on a cluster where that has been turned off, nested queries stop working entirely. Aggregating over nested fields also costs more than it looks: a `nested` aggregation descends into the child documents, so the bucket collection runs over the inflated document count, and getting back to parent-level metrics needs `reverse_nested`. ## Mitigations - **Bound the array.** Nested is a good fit when the many-side is small and has a natural ceiling — sizes of a garment, addresses of a customer. It is a bad fit when the many-side grows without limit. - **`include_in_parent` / `include_in_root`.** These mapping parameters additionally copy the child's values into the parent (or root) document so that ordinary, cheap queries can run on the flattened copy while correlated queries use the nested form. The cost is duplicated index data. - **Split the churn out.** If children change constantly and parents rarely, a parent-join field or separate child documents avoid rewriting the parent on every child change — at the price of slower queries and application-side stitching. - **Denormalize.** One document per child entry, with parent fields copied in, removes the multiplication problem entirely: the physical document count is the same as with nested, but there is no block rewrite and no special query syntax. ## How to check before shipping Measure with real data. Index a representative sample, compare `_cat/indices` `docs.count` against a `_count`, look at store size per business entity, and time a realistic update. The ratio you find — physical documents per entity, and documents rewritten per update — is the number that decides whether nested is affordable.