Elasticsearch Shard Calculator
Calculate how many primary shards an index needs from data volume and growth, check the shard count against node heap, and size a rollover policy that avoids oversharding.
Last reviewed by the Radiatus Cloud team
Want this automated for your stack?
We build CI/CD, Kubernetes & IaC pipelines that scale.
Oversharding is the most common failure mode
Every shard is a Lucene index with its own file handles, memory for segment metadata and a share of the cluster state. A thousand tiny shards cost far more than fifty appropriately sized ones and provide no benefit, because the parallelism they enable is already limited by the number of nodes and cores. Elastic's own guidance is to keep shards between ten and fifty gigabytes and to aim for fewer than twenty shards per gigabyte of heap on each node.
Primary shard count is fixed at creation
The number of primary shards cannot be changed after an index is created; changing it means reindexing into a new index. Replicas can be changed at any time. This asymmetry is why the primary count deserves thought and why time based indices with a rollover policy are the standard pattern for logs: each new index gets a fresh decision, and the previous ones can be shrunk, force merged and eventually frozen or deleted without touching the write path.
Replicas are availability and read throughput
One replica means the cluster survives a node loss without data loss and can serve reads from either copy. It also doubles the storage and the indexing work. Zero replicas is defensible only where the data can be regenerated from the source, and even then a single node failure takes the index offline. The calculator reports both the raw and the replicated storage requirement, because the second is what the disks actually have to hold.
Related tools
- CI/CD Security Gap Analyzer — Checklist based analyzer for CI/CD pipeline security gaps.
- Docker Security Scanner — A new tool extracted from the codebase.
- Terraform Scanner — A new tool extracted from the codebase.
- SQL Formatter — Format and indent SQL queries for readability. Handles joins, subqueries and CTEs, supports common dialects, and runs entirely in your browser.
Frequently Asked Questions
How large should a shard be?
Between 10 and 50 GB for most workloads. Smaller wastes overhead on metadata and file handles; larger makes recovery, relocation and snapshot restore slow. Time series data tolerates the upper end because it is rarely updated.
How many shards can a node hold?
Elastic recommends fewer than 20 shards per gigabyte of heap, so a node with 30 GB of heap should stay under about 600 shards. Exceeding it inflates cluster state, slows every master operation and eventually destabilises the cluster.
Can I change the shard count later?
Primary shards cannot be changed on an existing index; you reindex into a new one. Replicas can be changed at any time with a settings update. The shrink and split APIs can halve or multiply the count into a new index, with constraints.
Why use rollover instead of one big index?
Rollover creates a new index when a size, age or document threshold is reached, so each index gets a fresh shard decision and old ones can be force merged, shrunk and deleted without touching the write path. Deleting an index is instant, while deleting documents from one is expensive.
How much heap should a node have?
Half the available memory, capped at around 30 GB so the JVM keeps compressed object pointers. Above that threshold the pointers become uncompressed and a 32 GB heap has less usable capacity than a 30 GB one.
Privacy & Security
Everything runs in your browser; nothing is uploaded.
How to Use
Enter your data volume, retention and node count to get a shard layout and index template.
Disclaimer: This tool is provided "as is" without warranty of any kind. Results are for educational and utility purposes.