Zipkin Storage Calculator
Estimate Zipkin span storage from daily span volume, retention period, average span size and index overhead.
Inputs
Total spans reported to Zipkin per day after sampling.
How long Zipkin retains span data before it's purged.
Average serialized size of one span record.
Additional storage for indices on service name, span name, annotations and duration.
Total Storage Needed
52.50GB
Daily Storage (with Index Overhead)
7.500GB/day
Index Overhead
10,500,000,000bytes
Raw Span Data
42,000,000,000bytes
Step by step
Daily raw span data: spans × avg bytes
12,000,000 × 500
= 6.000 GB/day
Total raw data over retention
6.000 × 7
= 42.00 GB
Total with index overhead
42.00 × (1 + 25/100)
= 52.50 GB
How it works
Zipkin span storage grows with span volume and retention, plus the indices maintained for efficient lookups by service, span name, annotation and duration: storage = spans_per_day × retention × avg_span_bytes × (1 + index_overhead%). Index overhead exists because Zipkin backends (Elasticsearch, Cassandra, MySQL) maintain secondary indices to support the trace search UI, which adds to the raw span data footprint.
Formula
storage_GB_per_day = spans_per_sec × avg_span_bytes × 86400 / (1024^3)
- spans_per_sec
- Spans ingested per second
- avg_span_bytes
- Average span size in bytes
Frequently Asked Questions
Why does Zipkin need index overhead beyond raw span storage?
Zipkin's UI supports searching by service name, span name, tags/annotations, and duration ranges — supporting fast lookups on these dimensions requires secondary indices that consume additional storage beyond the raw span payloads.
How does Zipkin storage compare to Jaeger for similar volume?
Both follow a similar volume × retention × per-unit-size model; the main differences come from each project's specific serialization format and backend-specific overhead (index structure, replication) rather than a fundamentally different storage philosophy.
Can I reduce index overhead?
Some backends allow disabling or narrowing which fields are indexed (e.g. skipping annotation indexing) if your team primarily queries by trace ID or service name, trading some search flexibility for reduced storage.
Does Zipkin support automatic data expiration?
Most Zipkin storage backends support TTL-based expiration (e.g. Cassandra TTLs, Elasticsearch ILM) so that spans older than the retention window are automatically purged without manual cleanup jobs.
You might also need
- Tracing Storage CalculatorCommonly used together
- Distributed Trace Growth CalculatorCommonly used together
- Jaeger Capacity CalculatorCommonly used together
- Log Retention CalculatorAlso in Logging & Observability
- OpenSearch Index Size CalculatorAlso in Logging & Observability
- ELK Storage CalculatorAlso in Logging & Observability