What it does
VictoriaTraces is an open-source trace database from the VictoriaMetrics team. It ingests distributed spans over OpenTelemetry Protocol, stores them locally or across a cluster, and exposes Jaeger-compatible query APIs for trace search and visualization tools such as Jaeger and Grafana. Operators can set retention, run a single binary for a small deployment, or expand to a cluster as ingestion grows. The repository still labels the project as work in progress, so it is best approached as an evolving tracing backend rather than a finished managed observability service.
Put a trace store behind your collector
VictoriaTraces is a backend for traces, not the instrumentation library or a complete front-end observability suite. An application SDK or OpenTelemetry Collector must send spans to it. The official documentation describes starting a binary or container, setting a data directory and retention period, and querying through Jaeger Query Service APIs. Grafana or Jaeger Frontend can use those APIs, so a team can preserve an existing trace-viewing workflow while evaluating the new storage layer.
For an illustrative investigation, use the existing trace UI to find a slow request, inspect its spans, and compare service timing. VictoriaTraces can also sit alongside the VictoriaMetrics metrics and VictoriaLogs products, but that broader correlation depends on the surrounding tools and shared telemetry attributes. Trace-driven alerting is documented through companion alerting tools such as vmalert or Prometheus rather than as a replacement for an on-call system.
Check maturity and access controls
A single-node binary has no external storage dependency, and a cluster deployment is available when volume requires horizontal scaling. Retention is configurable and defaults to seven days in the current docs. The product is explicitly marked work in progress in its repository: on-disk formats and APIs may change before its first release. The docs also state that tenant IDs do not provide per-tenant authorization, and recommend protecting ingestion and query access with an authorization proxy. This matters if the store will be exposed beyond a trusted network. No traces were sent and no installation was tested for this listing.
Strengths
- Accepts OpenTelemetry spans and exposes Jaeger-compatible query APIs for use with existing trace clients.
- Can start as a single-node binary without an external database or object-storage dependency, with a cluster mode available for horizontal scaling.
- Provides configurable time-based and disk-space retention controls for self-hosted trace data.
Watch out for
- The repository identifies the project as work in progress and warns that APIs and on-disk data structures may change before the first release.
- It stores and queries traces but depends on external instrumentation or collectors and a separate UI for many investigation workflows.
- Tenant identifiers do not provide per-tenant authorization; the docs recommend placing an authorization proxy in front of the service.
Best for
- SRE and platform teams evaluating a self-hosted OpenTelemetry trace backend with Jaeger or Grafana compatibility.
- Teams that want to manage trace retention and storage directly and can accommodate an evolving project.
Sources
- VictoriaTraces: Fast, Open Source Distributed Tracing at Scale (Oct 26, 2026)
- VictoriaTraces (Oct 26, 2026)
- GitHub - VictoriaMetrics/VictoriaTraces: Fast and easy to use database for traces (Oct 26, 2026)
- VictoriaTraces/LICENSE at master · VictoriaMetrics/VictoriaTraces (Oct 26, 2026)