Elasticsearch hot, warm, cold & frozen sizing

In short

• Regular tiers (hot, warm, cold) store dataset × (1 + replicas) on local disk. Searchable snapshots store one copy locally (cold) or only a cache (frozen), and the full dataset in the repository.
• For long retention, where days land matters more than any other input: in the illustrative example below, the same year of 250 GB/day needs 268.4 TB of local disk on regular tiers and 33.7 TB with 335 frozen days.
• Provision for a utilization target, not for 100%: the default plan divides usable data by 85%.

When to use each tier

Tiers are about access pattern, not age alone: if a team searches 30 days back every morning, those 30 days belong on hot or warm regardless of what the ILM policy template suggests.

Local disk vs snapshot repository

Moving data into searchable snapshots does not delete storage; it moves it. In the one-year layout with 60 fully mounted cold days and 275 frozen days, nodes need 53.7 TB and the repository holds 104.7 TB including growth. The repository becomes part of the recovery path: a lost searchable-snapshot shard is restored from it, so its availability and throughput matter as much as node disks.

Worked example: one year at 250 GB/day

Illustrative example 250 GB/day of raw data, factor 1.0, one replica on regular tiers, 25% growth, 85% planning utilization, kept 365 days. Three layouts:

The all-regular layout is dominated by 335 cold days stored twice. Moving them to frozen cuts local provisioned disk by 7.97×, at the cost of slower searches on anything older than 30 days and a 104.7 TB repository. The middle layout keeps two months searchable at local speed for 20 TB more node disk than going straight to frozen.

Cold regular vs fully mounted

In the 90-day reference scenario (7 hot, 23 warm, 60 cold), regular cold needs 44.1 TB of cold-node disk; fully mounted needs 22.1 TB, plus 18.8 TB in the repository. Choose fully mounted when:

• you have the Enterprise subscription searchable snapshots require on self-managed clusters;
• the repository can restore a lost shard within your recovery objective;
• you want cold searches at local-disk speed without paying for replicas.

Keep regular cold indices when the data is still updated, when the repository is remote and slow, or when you need replicas for search throughput rather than resilience. Open the fully mounted cold scenario in Elastic.

Sizing the frozen cache

Frozen nodes keep a shared cache of recently read data and fetch the rest from the repository. ObservKit's 10% default is a planning assumption, not an Elastic recommendation. A better estimate is the share of frozen data your searches actually touch.

Hypothetical example 335 frozen days hold 83.8 TB. At 10% the cache is 8.4 TB. If investigations routinely read the most recent 90 frozen days, the working set is about 27% of the frozen range (90 ÷ 335): the cache becomes 22.6 TB and frozen provisioned disk 31.4 TB. Open the 27% cache scenario in Elastic.

Frozen nodes dedicate 90% of their disk to the shared cache by default, which is why frozen provisioned disk is the cache divided by 0.9 rather than by the 85% target.

Disk utilization

Elasticsearch evaluates disk watermarks per node: at the 85% low watermark it stops allocating shards to the node (primaries of new indices excepted), at 90% it relocates shards away, at 95% it applies a read-only block to indices with shards there. Dividing usable data by 0.85 keeps the average at the low watermark; it does not guarantee each node stays below it. Uneven shard sizes and node failures push individual nodes higher, so treat 85% as an upper bound for planning, not a target to fill.

On large disks the default low.max_headroom of 200 GB caps required free space, so a 10 TB node reaches its low watermark at about 98% used. That gives more usable space per node, but ObservKit does not model node sizes and keeps the aggregate 85% target.

Common mistakes

1. Choosing tiers by age templates instead of access. If dashboards read 30 days and hot holds 7, most searches hit warm disks sized for occasional reads.
2. Counting replicas on searchable snapshots. One replica on 60 fully mounted cold days doubles cold disk from 22.1 TB to 44.1 TB for no resilience gain; the repository already provides it.
3. Forgetting the repository budget. The frozen-after-30-days layout needs 104.7 TB of object storage. It is cheaper than node disk, not free.
4. Setting the frozen cache from a default. A cache smaller than the working set turns every search into repository reads; the 10% vs 27% example changes frozen disk from 11.6 TB to 31.4 TB.
5. Treating snapshots for backup as searchable snapshots. Regular snapshots of hot and warm data are backups and need their own repository capacity; the model does not include them.

Decision table

What the model does not cover

• Node counts, RAM-to-disk ratios and CPU for indexing and search.
• Regular snapshot backups of hot, warm and regular cold data.
• Per-node watermark behavior, uneven shard placement and the 200 GB max-headroom cap.
• Merge, translog and recovery peaks that temporarily need extra space.
• Repository request costs and restore throughput.

Sources

• Data tiers — Elastic documentation.
• Searchable snapshots — Elastic documentation: fully vs partially mounted, no replicas, shared cache defaults, subscription.
• Cluster-level shard allocation and routing settings — Elasticsearch reference: watermarks and low.max_headroom.
• Size your shards — Elastic documentation.

Last reviewed: October 2026 · Elasticsearch Sizing Calculator · Capacity Planning · Methodology