OpenSearch Index Size Calculator
Estimate OpenSearch/Elasticsearch index size from document count, average document size, replica count and compression ratio.
Inputs
Total number of documents to be stored in the index.
Average size of one document's source JSON before indexing overhead.
Number of replica shards per primary shard.
Effective storage reduction from codec compression (best_compression typically 1.2-1.5×).
Estimated Index Size
14.67GB
Estimated Index Size
0.014TB
Effective Size per Document
3,150.8bytes
Raw Size with Replicas
20,000,000KB
Step by step
Raw size: docs × avg doc size
5,000,000 × 2KB
= 10,000,000 KB
With replicas: raw × (1 + replicas)
10,000,000 × (1 + 1)
= 20,000,000 KB
Index size: with-replicas ÷ compression
20,000,000 ÷ 1.3
= 14.67 GB
How it works
OpenSearch and Elasticsearch store a primary copy of every document plus one full copy per configured replica, then apply codec-level compression to the stored segments: index_size = docs × avg_doc_size × (1 + replicas) ÷ compression_ratio. Because replicas are full data copies (not just checksums), replica count multiplies storage directly, while compression works against the combined primary+replica footprint.
Formula
index_size_GB = docs × avg_doc_size_KB × (1 + replicas) / compression_ratio / (1024 × 1024)
- docs
- Total document count
- avg_doc_size_KB
- Average document size (KB)
- replicas
- Number of replica shards per primary
- compression_ratio
- Codec compression factor
Frequently Asked Questions
Why do replicas multiply storage instead of just adding overhead?
Each replica shard is a complete copy of its primary shard's data, kept in sync for search availability and resilience — so replica_count=1 doubles stored data, not just adds a small overhead.
What compression ratio is realistic for OpenSearch?
The default codec typically achieves modest compression (~1.1-1.2×); switching to `best_compression` (which uses DEFLATE) commonly reaches 1.3-1.6× at some CPU and indexing-latency cost.
Does the indexed size ever exceed the raw source document size?
Yes — inverted indexes, doc values, and stored fields can add overhead beyond the raw JSON source, especially for heavily analyzed text fields; the avg_doc_size input should reflect actual observed index footprint per doc where possible, not just raw JSON size.
How does this relate to shard count?
This calculator estimates total index size regardless of shard count; shard count instead determines how that total is distributed across primary shards, which affects query parallelism and per-shard resource usage.
You might also need
- ELK Storage CalculatorCommonly used together
- Log Search Performance CalculatorCommonly used together
- Log Ingestion CalculatorCommonly used together
- Log Compression CalculatorCommonly used together
- Observability Cost CalculatorCommonly used together
- Zipkin Storage CalculatorAlso in Logging & Observability