Jaeger vs Zipkin vs Tempo (July 2026): Tracing Backends
TL;DR: All three store distributed traces; OpenTelemetry made the instrumentation identical. Jaeger is the CNCF-graduated standalone choice, Zipkin is the stable veteran for legacy B3 estates, and Tempo wins on cost at volume by replacing the trace database with object storage. Put an OTel Collector in front and the backend stays swappable.
Spec comparison
| Spec | Jaeger | Zipkin | Tempo |
|---|---|---|---|
| Origin | Uber, 2015: CNCF graduated | Twitter, 2012 (OpenZipkin) | Grafana Labs, 2020 |
| License | Apache 2.0 | Apache 2.0 | AGPLv3 |
| Native ingest | OTLP-native (v2 is built on the OTel Collector) | Zipkin JSON/B3; OTLP via exporter or collector | OTLP-native (also accepts Jaeger/Zipkin formats) |
| Storage | Cassandra, Elasticsearch/OpenSearch, Badger | Cassandra, Elasticsearch, MySQL, in-memory | Object storage (S3, GCS, Azure Blob) |
| Indexing model | Full span indexing in the backing store | Full span indexing in the backing store | No index, trace-ID lookup + TraceQL over object storage |
| Query interface | Jaeger UI | Zipkin UI (Lens) | Grafana + TraceQL |
| Cost at scale | High: driven by the Cassandra/ES cluster | High: same database-bound economics | Low, object storage at cents/GB |
| Development pace (2026) | Active: v2 rearchitecture on OTel | Maintenance mode: stable, few new features | Active, TraceQL and metrics-generator evolving |
| Operational footprint | Collector + query + a database cluster to run | Single jar is easy; production store is the hard part | Stateless components + a bucket; monolithic or microservices mode |
| Best for | Standalone tracing with a mature UI and CNCF pedigree | Legacy estates already instrumented with Zipkin/B3 | High-volume tracing on a budget, Grafana-centric stacks |
Feature matrix
| Capability | Jaeger | Zipkin | Tempo |
|---|---|---|---|
| Native OTLP ingest | ✓ | ~ | ✓ |
| Object-storage backend (no DB cluster) | ✗ | ✗ | ✓ |
| Search spans by tag/attribute | ✓ | ✓ | ✓ |
| TraceQL query language | ✗ | ✗ | ✓ |
| Service dependency graph | ✓ | ✓ | ~ |
| Trace-to-logs / trace-to-metrics links | ~ | ✗ | ✓ |
| Multi-tenancy built in | ~ | ✗ | ✓ |
| Helm chart / K8s operator | ✓ | ~ | ✓ |
| Managed cloud offering | ~ | ✗ | ✓ |
| Active feature development in 2026 | ✓ | ~ | ✓ |
A short history, and why it matters
Zipkin (Twitter, 2012) was the first widely adopted open-source implementation of Google's Dapper paper, and its B3 propagation headers became a de facto standard. Jaeger (Uber, 2015) followed with a more scalable architecture and became a CNCF graduated project. Tempo (Grafana Labs, 2020) arrived after OpenTelemetry had already won the instrumentation layer, and it made a different architectural bet: if the OTel Collector handles ingestion and Grafana handles visualization, the backend's only job is storing and retrieving traces cheaply. That history explains the 2026 market: the interesting differences are no longer about SDKs or wire formats (OTLP everywhere), but about storage economics and query models.
The storage economics
Jaeger and Zipkin index every span into a database (Cassandra or Elasticsearch/OpenSearch in production) so the cost of tracing scales with the cost of running that stateful cluster: nodes, replicas, compaction, reindexing. Tempo inverts the model: traces are compressed into columnar Parquet blocks on S3/GCS/Azure at cents per gigabyte, only the trace ID is indexed, and TraceQL answers attribute searches by scanning blocks in parallel. The trade-off is real (worst-case searches are slower than a hot Elasticsearch index) but for most teams the ability to retain 100% of traces for weeks instead of aggressively sampling to protect the database is worth far more. This economic profile is why high-volume shops and Grafana Cloud both standardized on Tempo, and why Grafana's tracing stack features prominently in our Grafana alternatives and Datadog alternatives analyses.
Which should you choose?
- Instrument with OpenTelemetry SDKs and route through an OTel Collector no matter what. All three backends ingest what the Collector exports, so the choice stays reversible.
- Already on the Grafana stack (Loki, Mimir, Grafana dashboards)? Tempo: trace-to-logs and trace-to-metrics links plus shared operations make it the default.
- High trace volume and a storage budget? Tempo's object-storage model is the only one where keeping 100% of traces is economically sane.
- Want a standalone tracing system with its own mature UI and no Grafana dependency? Jaeger, and its v2 architecture means you are running OTel components anyway.
- Existing services instrumented with Zipkin/B3? Keep Zipkin running, or point Zipkin-format exporters at Tempo/Jaeger (both accept the format) and migrate gradually.
- Greenfield in 2026: shortlist is Tempo vs Jaeger. Zipkin only enters on legacy grounds.
FAQ
Is Zipkin still worth choosing in 2026?
Only if you already run it. Zipkin is stable and battle-tested, but it is effectively in maintenance mode while Jaeger and Tempo actively evolve around OpenTelemetry. For an existing estate instrumented with B3 headers it keeps working fine; for a new deployment, Jaeger or Tempo ingest OTLP natively and have far more momentum.
How does Jaeger v2 relate to OpenTelemetry?
Jaeger v2 was rebuilt on top of the OpenTelemetry Collector framework, so a Jaeger v2 binary is essentially an OTel Collector distribution with Jaeger storage and query components. Jaeger deprecated its own client SDKs years ago in favor of OpenTelemetry SDKs, so instrumentation is identical whether your backend is Jaeger, Tempo, or a SaaS vendor.
Why is Grafana Tempo cheaper to run at scale?
Because it removed the database. Jaeger and Zipkin index every span into Cassandra or Elasticsearch, so trace volume translates directly into an expensive stateful cluster. Tempo writes compressed trace blocks to object storage at cents per gigabyte, indexes only the trace ID, and answers attribute searches by scanning columnar Parquet blocks with TraceQL: trading some query latency for an order-of-magnitude storage saving.
Do I need Elasticsearch or Cassandra to run Jaeger?
For production, effectively yes: Elasticsearch/OpenSearch or Cassandra are the supported scalable backends, and the embedded Badger store is single-node. That backing cluster is where most of the Jaeger operational cost lives, which is exactly the cost Tempo eliminates with object storage. For small setups, Jaeger all-in-one with Badger is fine for development.
Which tracing backend should I pick with the OpenTelemetry Collector?
Instrument with OTel SDKs and put an OTel Collector in front regardless of backend, then the backend becomes a swappable implementation detail. From there: pick Tempo if you already run Grafana or care about storage cost at volume, Jaeger if you want a standalone CNCF-graduated system with its own UI, and stay on Zipkin only to serve an existing B3-instrumented estate.
Tracing services is solved. Tracing agents is not.
Jaeger, Zipkin, and Tempo all answer the same question: what did your services do to each other. In 2026 there is a newer question they were never designed for: what did your AI agents do to your services, which agent invoked which tool, under which identity, at what cost, and was it allowed to? Swfte Nexus applies the tracing mindset to that layer: it captures every AI-agent action via runtime hooks, traces agents, identities, and connections the way a span traces a request, enforces policy in-flight, and attributes AI spend per agent. Your trace backend shows the request path; Nexus shows the actor behind it, see agent observability for how the two views combine.