# Why default number\_of\_shards is 1 in future release

**URL:** <https://discuss.elastic.co/t/why-default-number-of-shards-is-1-in-future-release/155814>\
**Category:** Elasticsearch\
**Created:** [November 8, 2018, 3:26am UTC](https://discuss.elastic.co/t/why-default-number-of-shards-is-1-in-future-release/155814 "2018-11-08T03:26:36Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![narasimhasv](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/narasimhasv/32/37397_2.png) [@narasimhasv](https://discuss.elastic.co/u/narasimhasv)\
**Post date:** [November 8, 2018, 3:26am UTC](https://discuss.elastic.co/t/why-default-number-of-shards-is-1-in-future-release/155814/1 "2018-11-08T03:26:36Z")

</div>

older and current version of elasticsearch default number\_of\_shards is 5 so that it distribute and parallelize operations across shards thus increasing performance/throughput  
but why in the future releases default value for number\_of\_shards is 1 ?

---

<div class="post-metadata">

**Author:** ![TimV](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/timv/32/13162_2.png) [@TimV](https://discuss.elastic.co/u/TimV)\
**Post date:** [November 8, 2018, 3:42am UTC](https://discuss.elastic.co/t/why-default-number-of-shards-is-1-in-future-release/155814/2 "2018-11-08T03:42:30Z")

</div>

5 is not a univerally better number of shards than 1.  
For some use cases 5 is fine, but for other use cases, 3 would be better, or 9, or ...  
In other cases you want 1 shard, and 4 replicas (or 9 replicas) because you have a relatively small amount of data, but heavy search workloads.

The best practice is to set the number of shards on an index-by-index basis based on the number of nodes you run, your ingest method, your search style, and any data rollover you do.  
While 5 wasn't a _bad_ default, it was by no means "the right answer" for all users.

The problem with a default of 5 is that it for many use cases - particularly logging and metrics - it causes significant over-sharding. We see far more issue caused by clusters with too many shards than clusters with not enough.

Having too few shards tends to show up relatively quickly once you do any sort of performance measurement and optimisation. Having too many shards tends to show up weeks or months _after_ production deployment when you end up with 3 months worth of time-based indices, each configured with 5 shards.

A default of 1 prevents customers from running into the oversharding problem that we see a lot of, and encourages those who want to optimise for performance to actually think about the right number for their usage (rather than simply relying on 5).

And we have the [Split API](https://www.elastic.co/guide/en/elasticsearch/reference/6.4/indices-split-index.html) if you decide you need additional shards.

---

<div class="post-metadata">

**Author:** ![narasimhasv](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/narasimhasv/32/37397_2.png) [@narasimhasv](https://discuss.elastic.co/u/narasimhasv)\
**Post date:** [November 8, 2018, 3:58am UTC](https://discuss.elastic.co/t/why-default-number-of-shards-is-1-in-future-release/155814/3 "2018-11-08T03:58:15Z")

</div>

appreciate! your time for answering my query

---

<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 6, 2018, 3:58am UTC](https://discuss.elastic.co/t/why-default-number-of-shards-is-1-in-future-release/155814/4 "2018-12-06T03:58:23Z")

</div>

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