Calculate Jaeger collector and storage capacity needed for your trace volume.
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.
required_collectors = ceil(spans_per_sec / max_spans_per_collector_per_sec)
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.
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.
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.
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.