Estimate backend storage needs for Zipkin trace data at a given span volume.
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.
storage_GB_per_day = spans_per_sec × avg_span_bytes × 86400 / (1024^3)
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.
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.
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.
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.