Jaeger Capacity Calculator

Estimate Jaeger backend storage requirements from daily trace volume, retention period and average trace size, comparing Elasticsearch and Cassandra overhead.

Inputs

Traces per Daytraces/day

Traces retained per day after sampling.

Retention Perioddays

How long Jaeger retains trace data before deletion.

Avg Trace SizeKB

Average serialized size of one complete trace, including all spans.

Elasticsearch Backend Storage

74.77GB

Cassandra Backend Storage

176.24GB

Raw Trace Data (no backend overhead)

53.41GB

Daily Raw Trace Volume

7.63GB/day

Step by step

Daily raw trace data: traces × avg size
1,000,000 × 8KB
= 7.63 GB/day
Total raw data over retention
7.63 × 7
= 53.41 GB
Elasticsearch storage (×1.4 index overhead)
53.41 × 1.4
= 74.77 GB
Cassandra storage (×3 replication × 1.1 compaction)
53.41 × 3 × 1.1
= 176.24 GB

How it works

Jaeger's actual storage footprint depends heavily on which backend it uses: storage = traces_per_day × retention × avg_trace_size, then adjusted for backend-specific overhead. Elasticsearch adds indexing overhead (~1.4× raw data) for search capability, while Cassandra's default 3× replication factor for high availability, combined with compaction overhead, typically results in a larger total footprint despite simpler per-write storage.

Formula

required_collectors = ceil(spans_per_sec / max_spans_per_collector_per_sec)

spans_per_sec: Total spans ingested per second
max_spans_per_collector_per_sec: Maximum spans one Jaeger collector can process

Frequently Asked Questions

Should I choose Elasticsearch or Cassandra for Jaeger?

Elasticsearch offers richer ad-hoc query and search capability at query time, while Cassandra generally offers better write throughput and horizontal scalability for very high trace volumes — the storage tradeoff shown here is one factor among several (query patterns, operational familiarity) in that decision.

Why does Cassandra need 3x replication by default?

Cassandra's default replication factor of 3 ensures data survives node failures without loss, at the cost of storing three full copies of every trace — this can be tuned lower for non-critical trace data, trading resilience for storage savings.

Can I reduce Jaeger storage without changing retention?

Lowering the sampling rate feeding into Jaeger is the most effective lever, since it reduces traces_per_day directly — the same effect can't be achieved for a fixed retention period without dropping data granularity another way.

Does Jaeger support tiered/cold storage for older traces?

Yes, with backends like Elasticsearch you can implement index lifecycle management (ILM) to move older trace indices to cheaper storage tiers or delete them entirely once past a threshold, independent of the primary retention window.

You might also need

Tracing Storage Calculator Zipkin Storage Calculator Distributed Trace Growth Calculator