Free tool

Elasticsearch cluster sizing calculator

Turn log volume and retention into node counts per tier: hot, warm, cold and frozen, with replicas, watermark headroom, shard limits, a node-loss check and every step of the math shown.

Runs entirely in your browser. Nothing you enter is sent anywhere.

1. Data sources

Raw ingest per day, as the shippers read it. Give it as GB per day, or as events per second times the average event size. The tool starts with the worked example from the capacity planning guide: 2.0 TB a day, peak hour 3 times the average.

Index-size expansion ratio (indexed primary / raw) Default 1.10, the guide's measured example. Typical log data with default dynamic mappings and _source kept is around 1.0 to 1.5 (rule of thumb); careful mappings, best_compression and logsdb can bring it well below 1. Measure it: index a sample with the production template, force merge, then compare pri.store.size with the raw bytes sent.

2. Retention and replicas

Days spent in each tier, not cumulative. 0 means the tier is not used. The guide's example: 7 days hot, warm until day 30 (23 days), frozen until day 365 (335 days).

Hot days Hot replicasUsually 1. Hot buffer daysRule of thumb: 1. Rollover and the ILM move to warm are not instantaneous; cover however long the phase transition takes. Warm days Warm replicasUsually 1. Cold daysFully mounted searchable snapshots. Cold replicasUsually 0: the snapshot repository is the redundancy. Frozen daysPartially mounted searchable snapshots. No replica.

3. Node specification per tier

Usable disk per node after RAID and filesystem overhead. Defaults are the guide's example hardware.

Hot

Disk per node, TB RAM per node, GB Target disk use, %Rule of thumb: about 75%, so a node loss stays below the low watermark. Indexing per node, MB/sRaw-equivalent, primary plus replica work. 20 is the guide's assumption; load test yours with the production template.

Warm

Disk per node, TB RAM per node, GB Target disk use, %Rule of thumb: about 75%.

Cold

Disk per node, TB RAM per node, GB Target disk use, %Rule of thumb: about 75%.

Frozen

Disk per node, TBLocal disk for the shared cache. RAM per node, GB Cache as % of frozen data5% is the guide's assumption for searches that mostly touch recent months. The least predictable number in the plan: test it with your queries. Shared cache, % of diskElastic default for xpack.searchable.snapshot.shared_cache.size on a dedicated frozen node: 90%. Shared cache max headroom, GBElastic default for ...shared_cache.size.max_headroom: 100 GB. Cache = max(90% of disk, disk minus headroom).

4. Shards, limits and memory

Target primary shard size, GBElastic: 10 to 50 GB for logging. ILM rollover on max_primary_shard_size; the guide uses 50. Max docs per shard, millionsElastic: fewer than about 200 million. Used when an event size gives a document count. Rollover max_age, daysAssumed rollover age: each data stream makes at least one backing index per this many days, however small. 0 ignores age. Rule of thumb: 1. cluster.max_shards_per_nodeElastic default 1,000 per non-frozen data node. cluster.max_shards_per_node.frozenElastic default 3,000 per frozen node. Shard limit planning ceiling, %This tool's rule of thumb: plan to at most 85% of the shard limit. The guide rejects 98% of it and accepts 82%. Low disk watermark, %Elastic default 85%. The node-loss check must stay below it. Heap, % of RAMElastic: no more than 50% of RAM. Heap cap, GBDefault 30 GB. The compressed-oops threshold is near 32 GB and varies by JVM: 26 GB is safe on most systems, up to about 30 GB where the startup log confirms compressed oops. Recovery throughput, MB/sThe guide's assumption: 200. Throttled by indices.recovery.max_bytes_per_sec and by disk. Warn if a node rebuild exceeds, hoursYour risk tolerance. 12 is this tool's default.

5. Resilience

Tolerate the loss of one node per tier ZonesNode counts are rounded up to an equal number per zone.

With node-loss tolerance on, each tier must stay below the low watermark, and within the shard limit, after one node is lost, and has at least one node more than its copies of a shard. Elasticsearch never puts two copies of the same shard on one node.

The cluster you need

Per tier

Warnings and notes

Masters, coordinating and ingest nodes

Show the math, and export

The link carries every input in the part after #, which browsers do not send to any server. Pasted sample events are not included.

Read with this tool

Elasticsearch Capacity Planning for Logging: A Worked ExampleTurn GB per day of logs into node counts per tier: indexed size, replicas, retention, watermark headroom, shard counts and ingest rate, with all the math.Elasticsearch Shard Sizing: A Capacity Model for Shard CountsCompute shard size and count for time-series and search indices, read per-node shard limits, and fix oversharding with the exact APIs and the arithmetic shown.Elasticsearch Data Tiers: Hot, Warm, Cold, Frozen with ILMDesign hot, warm, cold and frozen tiers with ILM and searchable snapshots: tier preference, partial vs full mounts, a storage cost model and when frozen pays.Elasticsearch Disk Watermarks, Flood Stage and Headroom PlanningHow the low, high and flood stage disk watermarks work, why indices go read_only_allow_delete, how max_headroom changes the math, and how much disk to plan.