ELK Storage Calculator

Estimate Elasticsearch storage needs for an ELK stack from log volume and retention.

About ELK Storage Calculator

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

Worked example

With the default values below, ELK Storage Calculator returns Total Storage Needed of 2,307.69. Change any input above and every figure here is recalculated in your browser.

Inputs used

Daily Log Volumeaccepts 0–1,000,000 GB: 50 GB
Index Replicasaccepts 0–10 replicas: 1 replicas
Retention Periodaccepts 1–3,650 days: 30 days
Compression Ratioaccepts 1–10 ×: 1.3 ×

Results

Total Storage Needed: 2,307.69 GB
Total Storage Needed: 2.254 TB
Daily Storage (with Replicas): 100.00 GB/day
Effective Storage per Retained Day: 76.92 GB

Step by step

1Daily storage with replicas: daily volume × (1 + replicas)= 100.00 GB
2Raw storage over retention= 3000.00 GB
3Compressed storage: raw ÷ compression ratio= 2307.69 GB

Assumptions and limits

The result is derived only from the 4 inputs listed above. Anything not among them is not part of the calculation.
In particular, this calculator does not take inflation, tax or fees or charges into account.
Figures are rounded for display to 3 decimal places, so totals built from several rounded parts can differ slightly from the unrounded arithmetic.

How these calculators are built and tested is described on the Methodology page. If a figure looks wrong, please report it.

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.