Flattened fields turn Elasticsearch into a schema-on-read store where you index schemaless data under one mapping, then use ES|QL's FIELD_EXTRACT to pull out any JSON key you need to filter, group or join on, with predicates pushed into the columnar store. ES|QL now reads flattened fields . FIELD_EXTRACT pulls any key out of a schemaless JSON object so you can filter, group, sort and join on keys you never mapped.
The planner pushes those predicates into the columnar store rather than parsing the whole blob per row, which means dynamic JSON keys from OTel attributes, log labels, user metadata or whatever else you didn't want to map individually are queryable without causing a mapping explosion . Elasticsearch wants a schema. Every field you index has a mapping that defines its type, its analyzer (for text), and how it is stored. That schema makes storage compression efficient, with fast search and cheap aggregation. It becomes a liability the moment your data stops looking like a database table.
Log events where every service adds its own attributes. pod , and another labels. OpenTelemetry resource attributes, where the set of keys is defined by whatever agent happened to send the span. User-supplied metadata bags, feature flags, or tagging systems, where the keys are open-ended by design. If you map each key as its own field, the mapping grows unbounded. This is the classic "mapping explosion. " Thousands of dynamically created fields inflate the cluster state, slowing down every mapping update and eventually hitting the field limit. Each field also carries overhead in the index.
You pay a structural cost for keys you didn’t plan for and may query only once. The naive escape hatch is to store the whole object as a string and give up on querying its contents. That trades one problem for another: you keep the data but lose the ability to filter or group by anything inside it. The flattened field type is the better path. You can index an entire JSON object under a single mapped field, keeping the keys queryable with almost none of the mapping-explosion cost. This post covers how a flattened field stores the data on a disk and how ES|QL reads it back.