# Practical size for attachments **URL:** \ **Category:** Elasticsearch\ **Created:** [November 11, 2019, 5:52am UTC](https://discuss.elastic.co/t/practical-size-for-attachments/207273 "2019-11-11T05:52:18Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![DaveG](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/daveg/32/46195_2.png) [@DaveG](https://discuss.elastic.co/u/DaveG)\ **Post date:** [November 11, 2019, 5:52am UTC](https://discuss.elastic.co/t/practical-size-for-attachments/207273/1 "2019-11-11T05:52:18Z")
Hi All, For attachment data, is there a practical size limit to the content of the attachment? I wish to add multiple attachments to an index in a nested sub-object and there may be a lot of data. Is there a point where it is more practical to have an index (or multiple indices) of just attachment data? regards, Dave. ---
**Author:** ![dadoonet](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/dadoonet/32/137187_2.png) [@dadoonet](https://discuss.elastic.co/u/dadoonet)\ **Post date:** [November 11, 2019, 7:34am UTC](https://discuss.elastic.co/t/practical-size-for-attachments/207273/2 "2019-11-11T07:34:26Z")
I'd not store blobs in elasticsearch but just the extracted text. But there's indeed some limits. One of them is the http max size limit which is IIRC 100mb. ---
**Author:** ![DaveG](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/daveg/32/46195_2.png) [@DaveG](https://discuss.elastic.co/u/DaveG)\ **Post date:** [November 14, 2019, 1:12am UTC](https://discuss.elastic.co/t/practical-size-for-attachments/207273/3 "2019-11-14T01:12:59Z")
Hi David, Even for the extracted text the data could be large. I have pumped some 40Mb pdfs through the attachment ingest pipeline and they end up with 6-8 mb of text. I'm just looking for any indication from experience of what point this is no longer a good strategy, either search performance degrades, the indexed Json objects become unwieldy or anything else ... ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [December 12, 2019, 1:13am UTC](https://discuss.elastic.co/t/practical-size-for-attachments/207273/4 "2019-12-12T01:13:09Z")
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed. ---
**Author:** ![dadoonet](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/dadoonet/32/137187_2.png) [@dadoonet](https://discuss.elastic.co/u/dadoonet)\ **Post date:** [December 25, 2019, 7:10am UTC](https://discuss.elastic.co/t/practical-size-for-attachments/207273/5 "2019-12-25T07:10:08Z")
---
**Author:** ![dadoonet](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/dadoonet/32/137187_2.png) [@dadoonet](https://discuss.elastic.co/u/dadoonet)\ **Post date:** [December 25, 2019, 7:13am UTC](https://discuss.elastic.co/t/practical-size-for-attachments/207273/6 "2019-12-25T07:13:20Z")
Sorry for the late reply. In general, it's not efficient to store very big json documents as anytime you search for them, you will read by default the source of 10 documents from disk. This consume time, network bandwidth... Also, when Lucene segments need to be merged, you will end up with lot of IOS on disk. Same when a node leaves, lot of things have to be copied over the network. Keeping json documents as small as possible is better IMO. ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [November 4, 2022, 7:32am UTC](https://discuss.elastic.co/t/practical-size-for-attachments/207273/7 "2022-11-04T07:32:47Z")