Zipkin Storage Calculator

Estimate backend storage needs for Zipkin trace data at a given span volume.

About Zipkin Storage Calculator

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

Worked example

With the default values below, Zipkin Storage Calculator returns Total Storage Needed of 52.50. Change any input above and every figure here is recalculated in your browser.

Inputs used

Spans per Dayaccepts 0–1,000,000,000,000 spans/day: 12,000,000 spans/day
Retention Periodaccepts 1–3,650 days: 7 days
Avg Span Sizeaccepts 1–1,000,000 bytes: 500 bytes
Index Overheadaccepts 0–200 %: 25 %

Results

Total Storage Needed: 52.50 GB
Daily Storage (with Index Overhead): 7.500 GB/day
Index Overhead: 10,500,000,000 bytes
Raw Span Data: 42,000,000,000 bytes

Step by step

1Daily raw span data: spans × avg bytes= 6.000 GB/day
2Total raw data over retention= 42.00 GB
3Total with index overhead= 52.50 GB

Assumptions and limits

The result is derived only from the 4 inputs listed above. Anything not among them is not part of the calculation.
In particular, this calculator does not take inflation, tax or fees or charges into account.
Figures are rounded for display to 3 decimal places, so totals built from several rounded parts can differ slightly from the unrounded arithmetic.

How these calculators are built and tested is described on the Methodology page. If a figure looks wrong, please report it.

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.