ELK Storage Calculator
Estimate Elasticsearch storage needs for an ELK stack from daily log volume, index replicas, retention period and compression ratio.
Inputs
Raw log volume ingested per day, before replication and indexing overhead.
Number of replica shards per primary shard (0 = no replicas).
How long indices are kept before deletion/rollover.
Effective storage reduction from Elasticsearch's compression (best_compression codec typically 1.2–1.5×).
Total Storage Needed
2,307.69GB
Total Storage Needed
2.254TB
Daily Storage (with Replicas)
100.00GB/day
Effective Storage per Retained Day
76.92GB
Step by step
Daily storage with replicas: daily volume × (1 + replicas)
50 × (1 + 1)
= 100.00 GB
Raw storage over retention
100.00 × 30
= 3000.00 GB
Compressed storage: raw ÷ compression ratio
3000.00 ÷ 1.3
= 2307.69 GB
How it works
Elasticsearch storage for an ELK stack scales with raw log volume, the number of replica copies kept for resilience, the retention window, and how much the compression codec shrinks stored segments: storage = daily_volume × (1 + replicas) × retention ÷ compression_ratio. Replicas multiply storage directly since they're full copies of primary shard data, not just metadata.
Formula
totalStorage = dailyVolume × (1 + indexReplicas) × retentionDays / compressionRatio
- V_d
- Daily log volume in GB
- r
- Index replica count
- D
- Retention period in days
- c
- Compression ratio
- S
- Total storage needed in GB
Frequently Asked Questions
Why multiply by (1 + replicas) instead of just replicas?
The primary shard itself already accounts for 1× the data; each replica adds another full copy, so total copies = primaries + replicas = 1 + replica_count when there's exactly one replica setting applied uniformly.
What compression ratio should I expect?
Elasticsearch's default codec gives modest compression (~1.1-1.2×); switching to best_compression (DEFLATE) typically achieves 1.3-1.5× at the cost of some CPU and indexing/query latency.
Does this include Elasticsearch's own indexing overhead (inverted index, doc values)?
The compression ratio in this model is meant to net out both compression savings and indexing overhead into a single effective multiplier — for a more precise model, benchmark actual index size vs. raw source size on your own data.
Should hot/warm/cold tiering change this calculation?
Yes — tiered storage often reduces replica count or compresses more aggressively on older tiers; run this calculation separately per tier for a more accurate total.
You might also need
- OpenSearch Index Size CalculatorCommonly used together
- Log Ingestion CalculatorCommonly used together
- Prometheus Storage CalculatorCommonly used together
- Terraform State Size CalculatorCommonly used together
- PVC Size CalculatorCommonly used together
- Zipkin Storage CalculatorAlso in Logging & Observability