Estimate storage for application logs, security events, observability telemetry, and audit records from ingestion rate, retention, compression, stored copies, index overhead, and operating headroom.
| Stage | Capacity |
|---|---|
| Retained logical logs | — |
| Compression savings | — |
| Compressed payload | — |
| All stored copies | — |
| Index / metadata overhead | — |
| Free-space headroom | — |
| Provisioned capacity | — |
Results show decimal and binary units for the same byte count. They do not include a separate backup, cross-region copy, search cache, or transient migration space unless represented in your assumptions.
The table keeps ingestion, compression, copies, overhead, and headroom unchanged, then varies only retention. Use it to see the storage effect of policy changes.
| Retention | Logical logs | Capacity to provision |
|---|---|---|
| Enter valid assumptions to compare retention periods. | ||
logical bytes = ingest bytes per second × retention seconds
compressed payload = logical bytes ÷ compression ratio
all copies = compressed payload × total stored copies
stored before headroom = all copies × (1 + index overhead ÷ 100)
provisioned capacity = stored before headroom ÷ (1 − headroom ÷ 100)
Headroom is divided by the usable fraction, not merely added. For example, keeping 20% free means modeled data may occupy 80% of provisioned capacity, so the required capacity is stored bytes ÷ 0.80.
Important: this is a steady-state capacity model. It does not size ingest CPU, memory, IOPS, shard counts, query performance, network bursts, write-ahead logs during failure, or temporary disk needed for compaction and migration. Validate production sizing with observed data and platform guidance.
At 5 GB/day for 30 days, the logical retained volume is 150 GB. With 3:1 compression, that becomes 50 GB per copy. Two stored copies require 100 GB; 15% index and metadata overhead raises modeled use to 115 GB. Keeping 20% free requires 115 GB ÷ 0.80 = 143.75 GB of provisioned capacity, equal to about 133.88 GiB.
Application payload, collector traffic, and stored chunks can differ. Measure the closest reliable stage, then apply only the transformations that occur after it.
Structure, repetition, timestamp precision, stack traces, and encrypted or encoded fields change compression. Test representative production segments rather than copying a generic ratio.
Run hot, warm, and archive tiers separately when their retention, compression, copies, or overhead differ. Add their provisioned results afterward.
Expired logs may be removed asynchronously. Compaction and object lifecycle delays can create temporary storage above this steady-state estimate.
Use platform documentation to replace planning assumptions with measured or supported values. Grafana explains that Loki stores compressed chunks plus indexes and that retention-driven deletion is performed asynchronously by the Compactor. Elastic’s capacity-planning material likewise treats source volume, indexing/compression factors, replicas, disk thresholds, and error margin as separate sizing inputs.
Logical retained data equals ingestion bytes per second multiplied by retention seconds. The calculator divides by compression, multiplies by total stored copies, adds index and metadata overhead, then divides by the usable fraction remaining after headroom.
Use a ratio measured from representative production logs on the intended platform. A 3:1 ratio means three logical bytes occupy one compressed byte. Use 1:1 when no reliable measurement exists.
One primary plus one replica means two total stored copies. This calculator asks for total copies so the multiplier is explicit.
Logging platforms may store indexes, labels, segment metadata, transaction logs, caches, or other structures in addition to compressed log payloads. The amount depends on the product and data shape.
Use a representative sustained average for retained capacity, then run a peak or growth scenario separately. Storage bandwidth, queues, and ingest nodes must also survive bursts even when long-term volume is based on an average.
A decimal TB is 1,000,000,000,000 bytes. A binary TiB is 1,099,511,627,776 bytes. The calculator converts through bytes and reports both systems.
Not necessarily. Many systems delete expired data asynchronously through compaction, lifecycle, or cleanup processes, so actual usage can lag the configured retention period.
No. The calculation runs locally in the browser and does not send entered workload values to a server.
Use this estimate for early planning and scenario comparison. Validate procurement and production limits against measured ingest, platform retention behavior, storage architecture, failure domains, query requirements, and vendor sizing guidance.
Starlight Tools