Grafana Tempo vs Jaeger: when to choose each for self-hosted tracing
A platform team that must self-host distributed tracing should choose Grafana Tempo when its trace storage should be object storage only and Grafana is already the place engineers look at dashboards, and choose Jaeger when it already runs Elasticsearch, OpenSearch, Cassandra or ClickHouse and wants Apache-2.0 licensing with attribute-based search. Both accept OpenTelemetry data, so the choice is mostly about where traces live, how engineers find them and who will be paged when storage misbehaves.
Tempo fits teams that want the simplest storage footprint. The grafana/tempo project states that it requires only object storage to operate, and it accepts Jaeger, Zipkin, Kafka and OpenTelemetry formats and is queried with TraceQL. It is a strong match for trace-by-ID lookups launched from a metric exemplar or a log line, which is the metrics-to-traces workflow many Grafana users already run. Tempo is distributed under AGPL-3.0-only, so confirm with counsel whether that license works for your distribution and internal modifications. Ask your team how often engineers search by arbitrary span attributes, because TraceQL depth and the cost of broad searches should be tested on your own data before you commit.
Jaeger fits teams that already operate one of its supported backends and want Apache-2.0 licensing. Jaeger is a CNCF graduated project, graduating in October 2019, and its storage policy covers Elasticsearch, OpenSearch, Cassandra and ClickHouse. If your operators already run index-heavy clusters, Jaeger adds no new storage skill. The decision turns on four questions: the search patterns your engineers actually use, the storage skills you already hold, your license posture, and how much of your debugging workflow depends on Grafana. Pilot both against a week of production-like traffic and confirm the supported backend versions with each project before you plan the rollout.
Which tracing platform fits which team scenario
This table maps common team situations to the platform that usually fits better and the condition that drives the choice. Read each row as a starting point: the deciding factor is usually what your team already operates, not the feature list alone. Scenario labels are illustrative, so check them against your own environment before deciding.
| Team scenario | Better fit | Condition that drives the choice |
|---|---|---|
| Already running Grafana and Loki (illustrative) | Grafana Tempo | Your team already operates the Grafana query and alerting path and object storage for logs. Tempo adds one more component to that stack, and traces can be viewed alongside logs and metrics in the same Grafana instance. |
| Existing Elasticsearch or OpenSearch cluster (illustrative) | Jaeger | Jaeger supports Elasticsearch and OpenSearch as storage backends under its storage support policy. If the cluster has capacity and staff who already run it, Jaeger reuses that investment instead of adding object storage operations. |
| Cassandra or ClickHouse expertise (illustrative) | Jaeger | Jaeger's storage support policy also covers Cassandra and ClickHouse. A team that already runs either database well can keep trace storage on a system it understands, which Tempo, which needs only object storage, does not use. |
| Ad hoc attribute search across high trace volumes | Depends on the search pattern | Tempo is queried with TraceQL and depends on how you plan to find traces. Jaeger's indexed backends suit attribute lookups, but index size and cluster load grow with volume. Load a representative sample of your traces and test your most common searches on each before committing. |
| Lowest storage footprint priority | Grafana Tempo | Tempo requires only object storage to operate, so there is no separate search index database to size and back up. Confirm retention, compaction and query latency targets for your own trace volume, because the footprint depends on sampling and retention settings. |
| Small platform team with limited database operations skills | Grafana Tempo | Tempo's single dependency is object storage, which many teams already run. Jaeger's operating effort depends on the backend you choose, and a self-managed Elasticsearch, Cassandra or ClickHouse cluster adds its own upgrade and capacity work. |
| Strict preference for a CNCF-hosted project | Jaeger | Jaeger is hosted by the CNCF and graduated in October 2019. Tempo is distributed under AGPL-3.0-only by Grafana Labs. Confirm that the AGPL terms and Grafana Labs' stewardship fit your governance and legal review. |
| Existing OpenTelemetry Collector pipelines | Either, depending on backend | Both platforms accept OpenTelemetry-based ingestion paths, so the Collector is rarely the deciding factor. Check which export formats and receivers your current pipeline uses before choosing the backend. |
How Tempo and Jaeger are built and what that means for operations
Tempo and Jaeger both collect traces from the same OpenTelemetry-era pipelines, but they store and search them very differently. The cards below separate what each one needs underneath it, because that choice sets how many stateful systems you run, which skills you need on the team, and how the bill grows with trace volume.
Tempo needs only object storage
Grafana Tempo is documented as requiring only object storage to operate, so the stateful footprint is the bucket plus Tempo's own components. Traces are stored as blocks in object storage and found through TraceQL, which means the main capacity question becomes how much you retain and how much you query. Ask your team which object store you will run, who owns its backups and replication, and whether your security baseline accepts it as the single durable store.
Tempo accepts several ingest formats
Tempo accepts Jaeger, Zipkin, Kafka and OpenTelemetry formats, so services instrumented for an older Jaeger client can often keep sending traces while you move the backend. That lowers migration risk when you change storage or query layers. Confirm which receivers and protocol versions your current agents emit, and test them against a non-production Tempo before you repoint production traffic.
Jaeger picks its own storage backend
Jaeger's storage support policy covers Elasticsearch, OpenSearch, Cassandra and ClickHouse, and you choose one of them. Each choice brings its own cluster to size, patch, back up and tune, so the operations load is the database you select, not only Jaeger itself. If your organization already runs one of these engines well, that existing skill is a real advantage. Confirm the version your chosen backend requires and who holds on-call for it.
Jaeger v2 reuses Collector components
Jaeger v2 uses many components from the OpenTelemetry Collector, so its ingest path shares configuration concepts, receivers, processors and exporters with the telemetry pipeline many teams already build. That overlap helps platform teams who standardize on the Collector. Check which Collector components your Jaeger version bundles and whether your pipeline needs any that are not included, because mixed stability levels across Collector components are documented per component.
Fewer stateful systems versus familiar tuning
Tempo trades a larger query and compaction design for fewer stateful dependencies, while Jaeger keeps a conventional storage engine your team may already tune for indexing, shards and retention. Choose Tempo if you want object storage to carry durability and your team is comfortable with a new query language. Choose Jaeger if an existing Elasticsearch, OpenSearch, Cassandra or ClickHouse practice would absorb the work. Ask each vendor or your own engineers to model retention and query load for your trace volume.
Licensing shapes the operating model
Tempo is distributed under AGPL-3.0-only, which applies when you modify and offer it over a network, while Jaeger is Apache-2.0 and hosted by the CNCF. Those licenses matter to legal and procurement teams even when you run both internally. Have counsel confirm whether your planned modifications, internal use or any customer-facing service triggers AGPL obligations before you commit to Tempo.
How Tempo and Jaeger compare on search, storage and licensing
This table compares Grafana Tempo and Jaeger on license, CNCF status, storage, query model, ingest formats and identity features. Where the supplied research does not settle a point, the cell tells you what to confirm with the project before you commit.
| Decision factor | Grafana Tempo | Jaeger |
|---|---|---|
| License | AGPL-3.0-only, the same copyleft family as Grafana itself since Grafana Labs moved Tempo off Apache License 2.0 in April 2021 | Apache-2.0, permissive, hosted by the CNCF |
| CNCF status | Not a CNCF project. Confirm the current governance model and release cadence directly with Grafana Labs. | CNCF graduated in October 2019 as the seventh top-level project |
| Storage requirement | Requires only object storage to operate, so no separate search index cluster is needed for trace storage | Storage backend chosen from Elasticsearch, OpenSearch, Cassandra or ClickHouse, each with its own operating model |
| Query language | TraceQL, Grafana's trace query language | Jaeger's own query model and UI. Confirm how it maps to your existing dashboards and alert rules. |
| Ingest formats | Accepts Jaeger, Zipkin, Kafka and OpenTelemetry formats | Native Jaeger ingest, with Jaeger v2 built on many OpenTelemetry Collector components. Confirm which formats your senders need. |
| Identity features | Confirm access control and SSO options for the Tempo query and ingest paths with Grafana Labs, since Grafana's identity features are documented separately | Confirm authentication options for the query UI and collector endpoints with the Jaeger project and your own gateway design |
| Operational footprint | Fewer stateful components when object storage is already in place, but you still run the Tempo services and the object store | Database-backed storage means you operate the chosen search or wide-column cluster alongside Jaeger |
| Best fit | Teams already running Grafana and object storage who want traces queried alongside metrics and logs | Teams that want a permissive license, a CNCF-graduated project and a storage backend they already operate |
What the AGPL and Apache-2.0 licenses mean for each tool
Legal and procurement teams need to know which license governs each component and what it asks of the organization. Grafana Labs relicensed Grafana, Loki and Tempo from Apache License 2.0 to AGPLv3 on April 20, 2021, so Tempo is distributed under AGPL-3.0-only. Jaeger is licensed under Apache-2.0 and has been hosted by the CNCF since it graduated in October 2019. The points below are a starting checklist, and counsel should confirm how each applies to your organization.
- Tempo license: Tempo is AGPL-3.0-only. Have counsel review the license text in the repository, not a summary.
- Jaeger license: Apache-2.0 is permissive and includes an express patent grant. Check whether it appears on your approved license list.
- Grafana Enterprise: Grafana Enterprise is offered as a non-AGPL commercial option. The supplied information does not establish a paid Tempo edition, so ask Grafana Labs in writing whether one exists and on what terms.
- Plugins and agents: Plugins, SDKs and agent software kept their other licenses after the 2021 change, so review each component in the stack separately.
- Support contracts: Neither license includes vendor support. Confirm who supports each product and under which contract.
Before the approval memo is written, check the license of every component you will deploy, including collectors and plugins.
Platform operators who patch upstream code take on the obligations that a modified copy carries. AGPL-3.0 includes a clause that applies when users interact with a modified version over a network, which is the main difference from a standard copyleft license. Apache-2.0 places fewer conditions on modified copies. Counsel should confirm how each clause applies to internal-only services before the team starts a fork.
- Network clause: A modified Tempo that serves internal users over a network may trigger AGPL source-offer duties. Ask counsel whether internal-only use changes the analysis.
- Patch ownership: Keep a record of each change to Tempo and the license it is released under, so you can show what was modified and when.
- Jaeger modifications: Apache-2.0 does not require you to share modifications with users. Keep the NOTICE and license files intact in every build.
- Upstream contribution: Check the contribution terms of each project before you send patches back, since they can set license or sign-off requirements.
- Build provenance: Record the commit, version and license for every internal build, so a later audit can trace what runs in production.
Before the first patch goes live, document which version you modified, where the source is published internally and who approves each change.
Teams that run official, unmodified releases carry the lightest license work. The main obligations are to keep license notices with the deployment and to track which version each environment runs. The lighter load still needs a process, because license terms attach to each version you ship. The illustrative case below shows where the process gets tested.
- Unmodified releases: Running an official release without code changes generally keeps obligations light. Confirm that your configuration files and deployment manifests do not count as modifications under the license.
- Notices in the bundle: Store license texts and notice files with the deployment artifacts, so the notices travel with every rollout.
- Image contents: Container images can bundle components under other licenses. Ask what each image contains and where the component list is published.
- Release tracking: Follow the release notes of Tempo, Jaeger and the collector in your pipeline, since each version can carry different terms or dependencies.
- Build evidence: Ask each project whether it publishes SBOM files with its releases. The OpenTelemetry Collector does, which makes its inventory easier to verify.
Illustratively, if an engineer adds a small change to a configuration template that alters application behavior, the change should be reviewed as a potential modification. For each component in the trace pipeline, confirm the license that applies to the exact version you deploy and where its notice file is kept.
What drives the running cost of Tempo and Jaeger
Running either tracing stack costs more than its license, which is free in both cases. The bill is driven by where trace data lands, how long it is kept, the compute that ingests and searches it, and the people who keep it running. Use these cards to decide what to put in a written scope and what to ask for in a quote.
Object storage volume and retention
Tempo keeps traces only in object storage, so its main recurring line is the bytes written and the retention window you set. Jaeger's storage cost depends on the backend you pick, so it is paid through that backend's disks or clusters instead. Ask for the expected trace volume per day, the sampling rate and the retention period in the quote, because each one scales the storage bill. Confirm which object storage service or self-hosted store your team will use and whether egress or request charges apply there.
Compute for ingest and query
Both systems need compute to receive spans, batch them, write them to storage and answer searches. Heavy TraceQL or Jaeger UI queries over long windows raise query compute, while high span rates raise ingest compute. Ask the implementer to size ingest and query components separately and to state which load level the sizing assumes. Confirm how the sizing changes when sampling is tuned down during incidents or peak traffic.
Database cluster behind Jaeger
Jaeger does not run without a storage backend, so the database cluster is a recurring cost unique to its chosen path. Elasticsearch, OpenSearch, Cassandra and ClickHouse each bring their own nodes, replicas, disks and upgrade cycles. Ask for the node count, replication settings, disk tier and backup method for the backend you choose. Also confirm who owns that cluster after handover, since it often becomes the largest operational dependency in the tracing stack.
Staff time for upgrades and tuning
Staff time is the largest cost that does not appear on an invoice. Tempo's single storage dependency reduces the number of systems to patch, while Jaeger's backend adds a second product lifecycle to track. Budget time for version upgrades, index or compaction tuning, capacity reviews and on-call response. Ask the implementer to state which tasks are one-time setup and which recur each month, and who on your side must sign off on each one.
Support and implementation fees
Neither project charges a license fee, but a fixed-scope implementation is still a one-time cost, and ongoing support or retainers are recurring. Grafana Labs offers paid products around its stack, so confirm whether any support you buy covers Tempo specifically. The Jaeger project is community maintained and vendor support comes from third parties. Request a written scope, deliverables, the support hours included and the upgrade and backup responsibilities before comparing quotes.
Retention and sampling decisions
Retention and sampling are the two settings that most directly change the recurring bill. Keeping every trace for a long period multiplies storage and query load, while head or tail sampling reduces volume but can hide rare failures. Set a written policy for which services keep full detail and for how long, and ask the quote to show the cost effect of each choice. Revisit the policy after the first quarter of real traffic, since estimates before launch are often wrong.
Moving traces from Jaeger to Tempo, or back, without losing history
This sequence runs both trace backends side by side, moves instrumentation and Collector exporters, and rebuilds Grafana data sources, queries and dashboards so that the trace data you keep stays searchable and each cutover can be verified before the old store is retired.
Inventory traces, queries and retention before changing anything
The platform team lists every service that sends traces, which SDKs or Collector pipelines export them, which Jaeger UI searches and dashboards people rely on, and what retention each store currently applies. The output is a written inventory that names the owner of each sender and each saved query. You know this step is done when every trace source appears in the inventory with its export path and an agreed cutover order.
Stand up Tempo alongside the existing Jaeger backend
The team deploys Grafana Tempo next to Jaeger, with Tempo writing to object storage as its only required dependency. Jaeger keeps its current storage backend, whether Elasticsearch, OpenSearch, Cassandra or ClickHouse, so no existing data is touched. Confirm the storage layout, access policies and the object storage configuration with your own security and storage teams, since those depend on your environment. Done means both backends accept test traces and the Tempo instance is reachable from Grafana.
Fan out traces to both backends through the Collector
Using the OpenTelemetry Collector, the team adds a second exporter so the same spans reach Jaeger and Tempo at the same time. Tempo accepts OpenTelemetry, Jaeger, Zipkin and Kafka formats, so the change is usually in Collector configuration rather than application code. Services are not modified in this step. Done means a sample trace from each service appears in both backends with matching trace IDs.
Cut over instrumentation and exporters service by service
The team switches each service's exporter to the Collector pipeline that targets Tempo, one service group at a time, and keeps the Jaeger exporter in place until the group is verified. Where services export directly from an SDK, the change is made in that service's configuration. Confirm the choice of exporter with each owning team. Done means each group sends only to Tempo for a full review window and no service is left with a broken export path.
Add Tempo to Grafana and rebuild dashboards and alerts
The team adds Tempo as a data source in Grafana, then rebuilds the trace panels, dashboards and alert rules that depended on Jaeger's UI or its query API. Searches are rewritten in TraceQL, since Jaeger queries do not carry over. Metric-based alerts that were built from trace data may need a new source, so each one is reviewed rather than copied. Done means every dashboard and alert the inventory listed has a Tempo equivalent that a named owner has checked against known traces.
Migrate history by policy, not by copying everything
Span data in supported formats can be re-exported from a Collector or replayed into the new store, but Jaeger's indexes and saved searches do not transfer. The team decides which historical traces need to be kept, usually those tied to open incidents or audit requirements, and exports only those. Confirm the export method for your Jaeger storage type and whether the exported data meets your retention and evidence needs. Done means a written list of retained historical data exists and each item has been opened in the target store.
Set the retention window and retire the previous store
The team sets how long traces stay in the previous store after cutover, based on the retention rules in the inventory, the incident review needs and any compliance obligations. The Jaeger backend is switched to read-only, then decommissioned once the window closes and nothing queries it. Confirm the window with the people who own incident response and compliance, since no default duration is set here. Done means the decommission date is recorded, the final export is verified and the old storage and its access paths are removed.
Where tracing implementations usually run long
Most tracing projects run long for reasons that have little to do with the backend choice. The first risk is instrumentation coverage: a Tempo or Jaeger deployment only shows what services emit, so teams should inventory which services already export spans through OpenTelemetry SDKs, which still rely on Jaeger or Zipkin client formats, and which have no tracing at all. Sampling is the second decision that quietly shapes cost. Head-based sampling in the SDKs is simple but drops error traces unless it is paired with tail-based sampling in the Collector, which needs enough memory to hold whole traces until they complete. Confirm the Collector layout (agent beside services, gateway in front of storage, or both) against the OpenTelemetry Collector deployment guidance before you size anything, because a single gateway that receives every span becomes the bottleneck that most early pilots never load-test.
On the Tempo side, projects tend to stall at trace-to-metrics linking and at search expectations. Tempo stores traces in object storage and is queried by trace ID or by TraceQL, so teams used to indexed attribute search in Jaeger often find that broad searches are slower until they plan for attribute-based queries and metrics generation. Grafana integration usually works well for linking traces to logs and metrics, but the links depend on consistent service names, resource attributes and label conventions across Prometheus, Loki and Tempo, and that naming work belongs in the plan. On the Jaeger side, the usual stall is operating the search cluster. Elasticsearch, OpenSearch, Cassandra or ClickHouse each bring their own shard, retention, index lifecycle and capacity tasks, and those tasks recur for as long as the platform runs. Ask the Jaeger and storage vendors for their current sizing and retention guidance, and budget the staff time to run that store, not only the initial install.
Questions teams ask before choosing between Tempo and Jaeger
Which costs more to run, Grafana Tempo or Jaeger?
Neither project has a license fee, so the difference is infrastructure and staff time. Tempo needs only object storage, so its main recurring costs are the bucket, the compute for its components and the storage growth your retention settings produce. Jaeger's cost follows its backend: Elasticsearch, OpenSearch, Cassandra or ClickHouse each need their own cluster with sizing, patching and backup. If your team already runs one of those stores well, Jaeger may add little infrastructure. If it does not, a new cluster is often the largest line item. Ask for both designs to be modeled on your trace volume, retention period and query load before comparing totals.
How long does a Tempo or Jaeger implementation take?
No fixed duration applies to either project, so the timeline comes from the written scope rather than from the tool alone. The main drivers are how many services emit traces, whether they use OpenTelemetry SDKs or existing Jaeger clients, the storage backend you choose, the retention and sampling policy, and how Grafana or other query tools connect to the store. Jaeger on an existing Elasticsearch or OpenSearch cluster has fewer moving parts than a new Cassandra or ClickHouse deployment. Tempo's single storage dependency simplifies the data layer but still requires agreed retention and access settings. DeployOpen plans and implements under fixed-scope agreements, so ask for milestones, dependencies and the named systems in scope.
What does a tracing rollout need from our own team?
Your team keeps ownership of decisions and of the systems around the tracing stack, whichever tool you choose. Expect to provide:
- Application owners who can add or confirm instrumentation, usually through OpenTelemetry SDKs or the OpenTelemetry Collector.
- Platform staff who can supply object storage or the search cluster, plus network paths, DNS, certificates and identity integration.
- A named approver for retention, sampling and access rules.
Jaeger also needs people who understand its chosen backend in production. Tempo asks less of the storage layer, but the team still needs to learn TraceQL for queries and to confirm how existing Jaeger users will work with it.
Can our engineers run Tempo or Jaeger in-house?
Often yes, if the team already operates the required infrastructure and can own upgrades and on-call. Confirm three things first: whether anyone has run the chosen storage backend in production, whether the team can maintain OpenTelemetry Collector configuration, and who responds when ingest or query latency degrades. Tempo's single dependency on object storage can be a smaller operational surface for a team that already runs S3-compatible storage. Jaeger suits a team with a mature Elasticsearch, OpenSearch, Cassandra or ClickHouse practice. DeployOpen can plan, implement, harden, back up, upgrade and document either stack in your infrastructure, or support it under a retainer. Decide on evidence from a pilot with your own trace volume.
Can Grafana Tempo ingest traces from Jaeger clients?
Yes. Tempo accepts Jaeger format traces, along with Zipkin, Kafka and OpenTelemetry formats, according to its repository. This lets you move ingestion before you move query tools. Confirm the exact receiver configuration and which Jaeger client versions work with your Tempo version in a test environment. Existing Jaeger UI users will see a different interface, because Tempo is queried with TraceQL. Running both systems in parallel during migration is one way to check that sampling, span attributes and dashboards match. Budget for duplicate storage during the overlap and plan the cutover of alerts that reference Jaeger endpoints. grafana/tempo repository
Does the AGPL license affect internal use of Tempo?
For purely internal use, the AGPL's obligations are often narrower than teams expect, but your legal counsel should confirm the position. Tempo is distributed under AGPL-3.0-only, and Grafana Labs relicensed Grafana, Loki and Tempo from Apache License 2.0 to AGPLv3 on April 20, 2021. The network clause is the part to review: it concerns modified versions offered to users over a network. If you change Tempo's code or offer a modified service to outside parties, review your obligations before release. Running unmodified builds for your own engineers is a different situation. Jaeger is Apache-2.0, a permissive license with fewer conditions to review. Grafana Labs licensing
How do we compare total cost in a quote?
Request each option priced on the same trace volume, retention, sampling and query load, with the storage backend stated. Break the quote into these parts:
- Labor for design, implementation, hardening and documentation, which is one-time.
- Storage and compute, which recur and grow with trace volume and retention.
- Ongoing support, upgrades and testing under a retainer, if you choose one.
- Any paid add-ons, requested separately, since both core projects are open source.
Ask for the assumptions, in-scope systems and exclusions in writing. DeployOpen does not publish a price list, and a quote follows from the written scope.
How DeployOpen helps choose and implement a tracing backend
DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a tracing decision, that means the work covers more than the backend itself: the OpenTelemetry Collector pipeline that receives spans, the choice of storage behind Tempo or Jaeger, the query and dashboard path your engineers use, and the access controls around all of it. DeployOpen does not favor Grafana Tempo or Jaeger. The useful first step is a written list of your trace volumes, retention expectations, the query patterns your teams need (for example, TraceQL searches by attribute versus lookups by trace ID), and which storage platform your operations team already runs well. Those answers determine which option fits, and they also determine the scope.
Most engagements are fixed-scope, so the scope, deliverables and timelines are agreed in writing before any work starts. A typical written scope for this decision would name the platforms in the evaluation, the environment where they will run, the identity integration for query access, the backup and retention approach for trace storage, and the documentation handed over at the end. DeployOpen does not publish a price list. A quote follows from that written scope, so the more precisely you define the components and environment, the more precisely the quote can reflect the work. Ongoing support, upgrades and continuous testing are available as retainers. DeployOpen can also run security testing against the tracing pipeline, including the collector endpoints, the query interfaces and the storage access paths, as part of a separate written scope. DeployOpen does not issue audit reports, attestations or certifications, so any compliance evidence it prepares would be reviewed by your independent auditor.
