# Is there any drawback of using best\_compression while indexing in Elasticsearch?

**URL:** <https://discuss.elastic.co/t/is-there-any-drawback-of-using-best-compression-while-indexing-in-elasticsearch/67842>\
**Category:** Elasticsearch\
**Created:** [December 2, 2016, 10:38am UTC](https://discuss.elastic.co/t/is-there-any-drawback-of-using-best-compression-while-indexing-in-elasticsearch/67842 "2016-12-02T10:38:41Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![roopendra](https://avatars.discourse-cdn.com/v4/letter/r/9d8465/32.png) [@roopendra](https://discuss.elastic.co/u/roopendra)\
**Post date:** [December 2, 2016, 10:38am UTC](https://discuss.elastic.co/t/is-there-any-drawback-of-using-best-compression-while-indexing-in-elasticsearch/67842/1 "2016-12-02T10:38:41Z")

</div>

I am performing some test on tuning disk space for Elasticsearch index. I found some good tips to compress the elasticseach index size. Especially, If your use case is only show dashboard in Kibana. During these indexes sizing analysis I observed `best_compression` gives me `21%` gain in disk space.

So my question is here,

> Is there any drawback of using **best\_compression** in elasticsearch?

If not, then why Elasticsearch not enable `best_compression` as a default `index.codec` instead of **LZ4 compression**?

I tried to find answer to these questions, but I couldn't succeed. Can you please help me to understand it better. Thanks.

---

<div class="post-metadata">

**Author:** ![ywelsch](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/ywelsch/32/7751_2.png) [@ywelsch](https://discuss.elastic.co/u/ywelsch)\
**Post date:** [December 2, 2016, 11:48am UTC](https://discuss.elastic.co/t/is-there-any-drawback-of-using-best-compression-while-indexing-in-elasticsearch/67842/2 "2016-12-02T11:48:00Z")

</div>

This blog post explains it best:

> **[Part 2.0: The true story behind Elasticsearch storage requirements](https://www.elastic.co/blog/elasticsearch-storage-the-true-story-2.0)**

> So what’s the catch? The stored fields (value of the \_source field) are what’s compressed, so there’s only a performance penalty due to decompression when the stored fields are returned in the query response. When the size=0 parameter is added to the request (as is recommended for pure aggregations queries and what Kibana does under the covers), there is no decompression penalty. There is a small performance penalty at index time; in many cases, people will gladly give up the extra CPU required for compression in exchange for disk space but you’ll have to consider this in the context of your requirements.

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\
**Post date:** [December 30, 2016, 11:48am UTC](https://discuss.elastic.co/t/is-there-any-drawback-of-using-best-compression-while-indexing-in-elasticsearch/67842/3 "2016-12-30T11:48:01Z")

</div>

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.