# Where is Elasticsearch storing unmapped field **URL:** \ **Category:** Elasticsearch\ **Tags:** synthetic-source\ **Created:** [July 23, 2026, 1:21pm UTC](https://discuss.elastic.co/t/where-is-elasticsearch-storing-unmapped-field/388701 "2026-07-23T13:21:54Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![ddoroshenko](https://avatars.discourse-cdn.com/v4/letter/d/b9e5f3/32.png) [@ddoroshenko](https://discuss.elastic.co/u/ddoroshenko)\ **Post date:** [July 23, 2026, 1:21pm UTC](https://discuss.elastic.co/t/where-is-elasticsearch-storing-unmapped-field/388701/1 "2026-07-23T13:21:54Z")
I have an index created with `index.mode=logsdb` and `index.mapping.source.mode=synthetic`. The mapping also has `dynamic: false`. If I index a document containing an unmapped field, for example: ```json { "@timestamp": "2026-07-23T15:30:45Z", "latency": 15, "foo": "bar" } ``` the `foo` field is: - not added to the mapping (as expected), - not searchable, - not returned by the fields API, - but it is still present in \_source. My question is: where is Elasticsearch storing this unmapped field? Since synthetic \_source is generally described as being reconstructed from doc\_values and stored fields, I'm trying to understand what happens in this case. `foo` has no mapping, so it shouldn't have doc values or an inverted index, yet it is still available in \_source. ---
**Author:** ![stephenb](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/stephenb/32/40856_2.png) [@stephenb](https://discuss.elastic.co/u/stephenb)\ **Post date:** [July 23, 2026, 1:54pm UTC](https://discuss.elastic.co/t/where-is-elasticsearch-storing-unmapped-field/388701/2 "2026-07-23T13:54:24Z")
Hi @ddoroshenko Ahhh I remembering wondering this myself a while ago. Run `POST /_disk_usage?run_expensive_tasks=true` So Elasticsearch keeps the unmapped content separately for **`_source`** reconstruction. Internally, these fields are stored special **`_ignore_source`** storage used by synthetic source for data that cannot be reconstructed purely from mapped field structures. It does not call out specifically each field. Curious if you are just curious 🙂 ... or seeing an issue Also to be clear you will only Actually get synthetic source if you have a license. ---
**Author:** ![ddoroshenko](https://avatars.discourse-cdn.com/v4/letter/d/b9e5f3/32.png) [@ddoroshenko](https://discuss.elastic.co/u/ddoroshenko)\ **Post date:** [July 23, 2026, 2:03pm UTC](https://discuss.elastic.co/t/where-is-elasticsearch-storing-unmapped-field/388701/3 "2026-07-23T14:03:09Z")
Hi @stephenb Thanks for the helpful answer! We're evaluating whether unmapped (non-indexed) fields will still be visible in Kibana when using synthetic `_source`. This question came up while investigating that behavior. ---
**Author:** ![stephenb](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/stephenb/32/40856_2.png) [@stephenb](https://discuss.elastic.co/u/stephenb)\ **Post date:** [July 23, 2026, 2:13pm UTC](https://discuss.elastic.co/t/where-is-elasticsearch-storing-unmapped-field/388701/4 "2026-07-23T14:13:16Z")
Assuming that you are seeing them in Discover etc... What version are you on? To validate you are actually using Synth Source `GET /_settings?include_defaults=true&flat_settings=true` Look for ````auto ... "index.mapping.pattern_text.disable_templating": "false", "index.mapping.semantic_text.use_legacy_format": "false", "index.mapping.source.mode": "SYNTHETIC", <<< THIS "index.mapping.synthetic_id": "false", "index.mapping.synthetic_source.skip_ignored_source_read": "false", ... ``` ```` ---
**Author:** ![ddoroshenko](https://avatars.discourse-cdn.com/v4/letter/d/b9e5f3/32.png) [@ddoroshenko](https://discuss.elastic.co/u/ddoroshenko)\ **Post date:** [July 23, 2026, 2:17pm UTC](https://discuss.elastic.co/t/where-is-elasticsearch-storing-unmapped-field/388701/5 "2026-07-23T14:17:46Z")
I'm on 9.4.x. I created the index manually via Dev Tools, so as I mentioned in my original post, synthetic `_source` is definitely enabled. 🙂 ---
**Author:** ![stephenb](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/stephenb/32/40856_2.png) [@stephenb](https://discuss.elastic.co/u/stephenb)\ **Post date:** [July 23, 2026, 3:35pm UTC](https://discuss.elastic.co/t/where-is-elasticsearch-storing-unmapped-field/388701/6 "2026-07-23T15:35:40Z")
Just because you enable synthetic in the settings does not mean it's actually taking effect... It requires a commercial enterprise license or trial license. If the cluster had a basic or platinum license and set it, it will accept the setting yeah but it will not actually take effect This is why I suggest running the above command to validate it. Just being clear in case of anyone else reads this. ---
**Author:** ![ddoroshenko](https://avatars.discourse-cdn.com/v4/letter/d/b9e5f3/32.png) [@ddoroshenko](https://discuss.elastic.co/u/ddoroshenko)\ **Post date:** [July 24, 2026, 5:36am UTC](https://discuss.elastic.co/t/where-is-elasticsearch-storing-unmapped-field/388701/7 "2026-07-24T05:36:36Z")
> [@stephenb](#): > > Just because you enable synthetic in the settings does not mean it's actually taking effect... It requires a commercial enterprise license or trial license. > > If the cluster had a basic or platinum license and set it, it will accept the setting yeah but it will not actually take effect > > This is why I suggest running the above command to validate it. > > Just being clear in case of anyone else reads thi @stephenb that's a very important point. Thanks for highlighting it. Yes, we have the appropriate license. I also checked the settings and confirmed that `index.mapping.source.mode` is indeed set to `synthetic`. ---
**Author:** ![davidwarner44](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/davidwarner44/32/147872_2.png) [@davidwarner44](https://discuss.elastic.co/u/davidwarner44)\ **Post date:** [July 24, 2026, 5:51am UTC](https://discuss.elastic.co/t/where-is-elasticsearch-storing-unmapped-field/388701/8 "2026-07-24T05:51:26Z")
`foo` is stored separately in Elasticsearch’s internal `_ignore_source` storage. Synthetic `_source` uses this to preserve unmapped fields, so they can still appear in `_source` even though they aren’t searchable or mapped.