Elastic101 – Best Practice #002: shard size
I've spent close to a decade running Elasticsearch clusters in production, from 3-node dev setups to multi-hundred-node deployments handling billions of documents a day.
One thing I've seen repeatedly in production is that teams either let shards balloon for years without noticing, or over-correct and split everything into tiny shards "to be safe."
Elastic101 – Best Practice #002 – Shard Size
Smaller shards increase overhead more cluster state to track, more per-shard costs (file handles, memory, translog), and more coordination work on every query.
Larger shards cause the opposite problem: recovery and rebalancing get painfully slow, and a single hot shard can bottleneck an entire index.
>The goal is to keep shard size around 50GB.
Pro tip: you cannot simply change the primary shard count of an existing index. If you need to change it, you typically need to use the Reindex API or the Shrink API, depending on the situation. Also, if you reindex a 200GB index, you should have at least 200GB of additional free disk space available in the cluster for the new index. Choose your primary shard count wisely from the start, fixing it later is expensive.
Previous Elastic101 best practices:
Try here: Searchali Elasticsearch Monitoring Connect your cluster in 10 seconds. No agent. No data leaves your machine.