Why is a string field in Elasticsearch usually mapped as text with a keyword sub-field?

## What a multi-field actually is A multi-field is a field mapping that declares extra sub-mappings under the `fields` parameter. When a document is indexed, Elasticsearch takes the single JSON value and feeds it to the parent mapping *and* to every sub-field mapping, writing several independent sets of index structures from one source value. The document itself is unchanged; `_source` still contains one `title`. Only the index gains extra entries. You address a sub-field by dotted path: if `title` is `text` with a sub-field named `keyword`, then `title` is the analyzed field and `title.keyword` is the verbatim one. The sub-field name is arbitrary — `keyword` is only a convention that dynamic mapping happens to use. ## Why the text-plus-keyword pair is the default The two string types answer different questions and neither can answer both. An analyzed `text` field supports `match`, phrase queries and relevance ranking, but stores no whole-value term and no `doc_values`, so it cannot be filtered exactly, sorted, or aggregated. A `keyword` field can do all of those and none of the full-text ones. When Elasticsearch meets a string with no explicit mapping, it refuses to guess and gives you both: ```json "title": { "type": "text", "fields": { "keyword": { "type": "keyword", "ignore_above": 256 } } } ``` That is why so many real queries and Kibana visualizations refer to `something.keyword`: the analyzed parent cannot serve a bucket aggregation, and the sub-field can. ## Beyond the default pair Multi-fields are a general mechanism for indexing the same text several ways: - **Different analyzers.** A parent `text` field with the `standard` analyzer plus a `title.english` sub-field using the `english` analyzer lets you query both and combine them: the stemmed sub-field boosts recall ("running" finds "run"), the exact parent boosts precision, and a `multi_match` across both usually ranks better than either alone. - **A different type.** A numeric-looking string can be indexed both as `keyword` and as a numeric sub-field if some queries need ranges and others need exact term lookups. - **Search-as-you-type or n-gram sub-fields.** Prefix matching gets its own analysis chain without polluting the main field. ## What it costs Each sub-field is a full set of index structures: its own postings, its own `doc_values` where applicable, its own norms. A `keyword` sub-field on a long free-text field is not free — you are storing the entire value again as a single term (up to `ignore_above`) plus doc values for it. On a large index of article bodies, an inherited `body.keyword` can be pure waste: nobody aggregates on article bodies, and any body over the character limit is silently absent from that sub-field anyway. Each sub-field also counts toward the index's field count, so dynamically mapping a wide, unpredictable document doubles your field growth. ## The operational gotcha Adding a new sub-field to an existing mapping is allowed — sub-fields are additive, and unlike a type change the request succeeds. But it only affects documents indexed *after* the change. Existing documents have no data in the new sub-field, so filters and aggregations on it silently under-report. To populate it you must rewrite the existing documents, typically with `update_by_query` on the same index or a reindex into a new one. Interviewers like this question because "the mapping update succeeded" and "the data is there" are two different things. The mirror-image gotcha is querying the wrong half. `{"term": {"title": "Wireless Mouse"}}` returns nothing because `title` is analyzed; `{"term": {"title.keyword": "Wireless Mouse"}}` works. A sort on `title` errors or is meaningless; a sort on `title.keyword` is correct. Half of "Elasticsearch returns no results" tickets are a missing `.keyword` suffix. ## How to decide, per field Start from usage, not from the default: - Searched full-text only (article body, description): plain `text`, drop the sub-field. - Filtered, sorted, faceted only (status, SKU, tenant ID, host name): plain `keyword`, no analyzed parent. - Genuinely both (product title, person name, tag that users also type into a search box): `text` with an explicit `keyword` sub-field, and set `ignore_above` deliberately. Writing the mapping explicitly costs a few minutes and removes a whole class of surprises: no silent 256-character truncation you did not choose, no doubled index for fields nobody facets on, and no `.keyword` archaeology when someone reads the queries a year later.