Skip to content

Victoria Stack

Summary

The Victoria Stack is a family of open-source (Apache 2.0) observability databases and tools from VictoriaMetrics, Inc.: VictoriaMetrics for metrics (MetricsQL, a PromQL-compatible language), VictoriaLogs for logs (LogsQL), and VictoriaTraces for traces (OTLP in, Jaeger and experimental Tempo APIs out), plus vmagent, vmalert, vmauth, vmbackup and a Kubernetes operator. Instead of one all-in-one backend it ships specialized single binaries with no external dependencies (no object storage, no Kafka, no ZooKeeper), each scalable from one node to an insert/select/storage cluster. Paid Enterprise builds add downsampling, retention filters, mTLS, vmgateway, vmanomaly and LTS releases. As of 2026-09: VictoriaMetrics v1.152.0, VictoriaLogs v1.52.0, VictoriaTraces v0.11.1 (still pre-1.0).

Key Facts

Attribute Detail
Latest Version (VictoriaMetrics) v1.152.0 (2026-09-14) — CHANGELOG
LTS lines (Enterprise) v1.148.4 and v1.136.18 (2026-09-11); new line every 6 months, 12 months support each
VictoriaLogs v1.52.0 (2026-07-16); GA since v1.0.0 (2024-11-12)
VictoriaTraces v0.11.1 (2026-09-16); 0.x since v0.1.0 (2025-07-28)
VictoriaMetrics Operator v0.74.1 (2026-08-04)
Release cadence VictoriaMetrics minor about every 2 weeks; VictoriaLogs and VictoriaTraces roughly monthly
License Apache 2.0 (all three databases and tools); Enterprise features under a commercial license
Governance Single-vendor project of VictoriaMetrics, Inc. (not a CNCF project)
Language Go
Repositories VictoriaMetrics, VictoriaLogs, VictoriaTraces, operator, helm-charts
GitHub stars (main repo) 16.7k+ (as of 2026-04)
Founded 2018 in Kyiv, Ukraine, by Aliaksandr Valialkin, Artem Navoiev, Dzmitry Lazerka and Roman Khavronenko; now headquartered in San Francisco and bootstrapped (The Register interview, 2023-12, About us)
Managed offering VictoriaMetrics Cloud (metrics; managed logs added in Q1 2026; VictoriaTraces deployment tiers listed in the Cloud docs as of 2026-09)

Architecture at a Glance

Collectors write through vmauth into three independent databases that share the same insert/select/storage pattern:

flowchart LR
    Agent["vmagent / OTel Collector / vlagent"] --> Auth["vmauth"]
    Auth --> VM["VictoriaMetrics<br/>vminsert, vmselect, vmstorage"]
    Auth --> VL["VictoriaLogs<br/>vlinsert, vlselect, vlstorage"]
    Auth --> VT["VictoriaTraces<br/>vtinsert, vtselect, vtstorage"]
    VT -.->|"built on"| VLE["VictoriaLogs engine"]
    Alert["vmalert"] --> Auth
    Grafana["Grafana / VMUI"] --> Auth
    Alert --> AM["Alertmanager"]

Details and the full topology: Explanation: Default Topology.

Core Databases

Component Signal Query Language / API Ingestion License
VictoriaMetrics Metrics MetricsQL (PromQL-compatible with intentional differences) Prometheus remote write, InfluxDB, Graphite, OpenTSDB, Datadog, NewRelic, OTLP, CSV/JSON Apache 2.0
VictoriaLogs Logs LogsQL Elasticsearch bulk, JSON lines, Loki push, OTLP, syslog, journald and more Apache 2.0
VictoriaTraces Traces Jaeger query API, LogsQL, experimental Tempo API (TraceQL subset) OTLP only (HTTP; gRPC when enabled) Apache 2.0

Edge Daemons and Tools

Tool Purpose Key Feature
vmagent Prometheus-compatible scraper and metrics router 20+ *_sd_configs service-discovery types, relabeling, stream aggregation, on-disk queue per remote
vmalert Alerting and recording rules Evaluates MetricsQL, LogsQL (type: vlogs) and trace rules
vmauth HTTP auth proxy, router, load balancer Basic/Bearer, JWT with OIDC discovery (v1.137+), browser SSO in tip; routes all three databases
vmbackup / vmrestore Snapshot backups to S3/GCS/Azure/filesystem Incremental uploads, server-side copy via -origin
vlagent, vtagent Log collector/replicator; basic OTLP trace forwarder (v0.11.0+) Kubernetes pod log discovery, replication
VictoriaMetrics Operator Kubernetes CRDs for the whole stack VMCluster, VMAgent, VMAuth, VLSingle, VLCluster, VTSingle, VTCluster, VMAnomaly and more
vmanomaly (Enterprise) Anomaly detection on metrics Writes anomaly scores back for vmalert

Evaluation

  • Why it is better: One design philosophy across signals — resource efficiency and near-zero tuning. Upstream claims VictoriaLogs uses up to 30x less RAM and 15x less disk than Elasticsearch and Loki, and VictoriaTraces up to 3.7x less RAM than Tempo; VictoriaMetrics is widely reported to need several times less RAM than Prometheus at high cardinality. Native Prometheus, Loki, Elasticsearch and OTLP ingestion means no translation tier. Stateless insert/select roles scale independently of storage.

  • When it fits (Applicability):

    • Kubernetes clusters with high label churn and cardinality
    • Long-term Prometheus storage with PromQL/Grafana compatibility
    • IoT or SaaS telemetry with millions of active series and per-customer tenants
    • Log volumes where Elasticsearch or Loki became too expensive
    • Teams wanting single binaries and local disks instead of object storage
    • Cost pressure from per-series SaaS pricing (Datadog, New Relic, Grafana Cloud)

  • When it does not fit:

    • You need object storage as the primary tier (Mimir, Thanos, Loki, Tempo)
    • You need mature trace querying (TraceQL, span metrics) today — VictoriaTraces is 0.x
    • You need profiles or one correlated UI out of the box

  • Pros and Cons:

Pros Cons
Low RAM and disk use (vendor and user reports) Three separate storage engines to run and back up
Apache 2.0 core (more permissive than AGPL) No built-in cross-signal correlation UI; relies on Grafana
Single binaries, near-zero config, no external deps VictoriaTraces is 0.x and less proven than Tempo
PromQL-compatible MetricsQL; Loki/ES/OTLP ingestion Downsampling, retention filters, mTLS, LTS are Enterprise-only
MetricsQL fixes PromQL rate/increase quirks Smaller ecosystem than Grafana's
Shared-nothing cluster, simple scaling Single-node VictoriaMetrics has no multitenancy
Community vmauth now has JWT/OIDC (v1.137+) No WAL: seconds of data can be lost on crash

  • Common Use Cases (official case studies):

    • Roblox: 5 billion active time series; 100% availability for three straight quarters
    • Spotify: replaced the internal Heroic system
    • CERN: real-time monitoring of the CMS detector
    • Grammarly: 10x lower cost and maintenance burden
    • Wix: 60% lower yearly infra cost after migration
    • Others: adidas, Brandwatch, Criteo, Naver, Razorpay, Dig Security, Sensedia
    • DreamHost: 76M active series, 80% lower memory use, 450k+ data points/s; published as a VictoriaMetrics blog case study, not on the docs case-study page

  • Licensing & Commercial Use:

    • Community: Apache 2.0, no copyleft obligations
    • Enterprise: downsampling, retention filters, vmbackupmanager, vmgateway, vmanomaly, mTLS, IP filters, auto-TLS, Kafka/PubSub, FIPS builds, LTS lines; -license key required. Evaluation licenses are free. Full list: Reference: Community vs Enterprise
    • VictoriaMetrics Cloud: managed service built on Enterprise, with fixed-price capacity tiers for VictoriaMetrics, VictoriaLogs and VictoriaTraces. The smallest tiers start at about $190/month; other tier prices appear only in the Cloud console; new accounts get $200 of credits for 30 days (Cloud billing docs, checked 2026-09-27). This replaces earlier ~$225/month single-node and ~$1,300/month cluster figures

  • Ecosystem & Data Connections:

    • Ingestion: Prometheus remote write, InfluxDB line protocol, Graphite, Datadog, NewRelic, OTLP, Elasticsearch bulk, Loki push, syslog, JSON lines
    • Querying: MetricsQL/PromQL, LogsQL, Jaeger query API, Tempo API (experimental)
    • Visualization: Grafana (Prometheus type, victoriametrics-logs-datasource plugin, Jaeger/Tempo types), built-in VMUI
    • Collection: vmagent, vlagent, OpenTelemetry Collector, Prometheus, Fluent Bit, Vector, Logstash, Promtail/Alloy
    • IaC: operator CRDs, Helm charts (victoria-metrics-k8s-stack and per-component charts)
    • Backup: vmbackup/vmrestore (metrics), partition snapshots + rsync/rclone (logs, traces)

  • Compatibility & Requirements:

    • Linux and macOS binaries; Docker images (VictoriaLogs/VictoriaTraces images are distroless since v1.52.0/v0.10.0); Kubernetes via operator or Helm
    • Zero external dependencies; local persistent disks (SSD recommended)
    • Single-node VictoriaMetrics recommended below ~1M samples/s ingestion
    • Cluster VictoriaMetrics with replication needs at least 2*RF-1 vmstorage nodes

  • Alternatives:

    • Grafana Mimir — horizontally scalable Prometheus on object storage, AGPL
    • Thanos — sidecar/object-storage long-term Prometheus
    • Prometheus — the standard single-node TSDB
    • InfluxDB — dedicated TSDB with its own query languages
    • Grafana Loki — label-indexed logs on object storage
    • SigNoz / OpenObserve — OpenTelemetry-native all-in-one backends
    • Elasticsearch/OpenSearch — full-text log search, heavier footprint

  • Migration & Lock-in Risks:

    • Low lock-in on metrics — PromQL queries and dashboards work; MetricsQL extensions are optional; vmctl migrates from Prometheus, Thanos, InfluxDB, OpenTSDB and remote-read sources
    • Low lock-in on logs — accepts Loki and Elasticsearch APIs; LogsQL is proprietary but export is JSON lines
    • Low lock-in on traces — OTLP in; Jaeger API out
    • From Prometheus: add a remote_write URL — zero downtime
    • From Loki / Elasticsearch: point shippers at /insert/loki/api/v1/push or /insert/elasticsearch/; keep old data queryable in the old system during transition

  • Community Health & Support:

    • Very active: VictoriaMetrics ships a minor release about every 2 weeks, with LTS backports
    • Public security advisories on GitHub (for example GHSA-f99m-22fh-qw96, fixed in v1.152.0)
    • Enterprise SLAs; community Slack; frequent engineering blog posts

Recent Developments (2025-2026)

Date Development
2025-07-28 VictoriaTraces v0.1.0 released as a separate repository
2026-01-02 VictoriaMetrics v1.133.0: per-partition IndexDB (one-time series re-registration on upgrade)
2026-02-27 v1.137.0: JWT authentication in community vmauth; -promscrape.dropOriginalLabels default false
2026-03-02 VictoriaTraces v0.8.0: experimental Grafana Tempo data source API
2026-05-20 VictoriaTraces v0.9.0: Tempo API extended for Grafana Traces Drilldown; per-query hidden span attributes
2026-06-17 VictoriaLogs v1.51.0: stricter LogsQL filter-pipe syntax; cluster protocol bump
2026-07-16 VictoriaLogs v1.52.0: distroless images, json_array_concat pipe
2026-07-30 Operator v0.74.0: VLDistributed CR for multi-region VictoriaLogs; network policy lookups
2026-08-05 v1.149.0: vminsert slowness-based rerouting on by default; delete endpoints POST-only
2026-08-14 VictoriaTraces v0.11.0: vtagent
2026-08-17 v1.150.0: multitenancy via AccountID/ProjectID headers enabled by default
2026-09-14 v1.152.0: fix for vmauth JWT match_claims authorization bypass; Go 1.27.1 builder
tip vmauth browser SSO via OIDC; VictoriaLogs -deleteAuthKey, POST-only internal endpoints

Topic Map

  • How-to Guides — deployment (binaries, Docker, Helm, operator), vmauth routing and security, upgrades, backups, troubleshooting, Commands & Recipes
  • Reference — versions and LTS policy, Community vs Enterprise, ports and API paths, deployment matrix, data model, MetricsQL/LogsQL, flags, benchmarks, cost, hardening, advisories
  • Explanation — topology, tri-role cluster pattern, storage engines and no-WAL design, VictoriaTraces on the VictoriaLogs engine, security and multitenancy model, open-core model
  • LGTM vs Victoria Stack — canonical head-to-head comparison
  • Observability Stacks Comparison — 7-way comparison with Coroot, SigNoz, SkyWalking, OpenObserve, LGTM and Monoscope
  • Grafana — visualization layer used with the Victoria Stack
  • LGTM Stack — Grafana's competing full-stack observability solution
  • OpenTelemetry — OTLP is accepted natively by all three databases
  • OpenTelemetry Collector — common collector in front of VictoriaTraces and VictoriaLogs
  • Observability 2.0 — wide events, which VictoriaLogs is optimized for
  • SigNoz, OpenObserve, Coroot — alternative stacks (Coroot can use VictoriaMetrics as a backend)
  • Kubernetes — main deployment target via the operator and Helm charts
  • Prometheus — the metrics standard that VictoriaMetrics is wire-compatible with (no dedicated topic yet)

Sources

Primary Sources

URL Source Kind Authority Retrieved Via Date
https://github.com/VictoriaMetrics/VictoriaMetrics repository primary web search 2026-09-25
https://docs.victoriametrics.com/ docs primary web search 2026-09-25
https://github.com/VictoriaMetrics/VictoriaMetrics/blob/master/docs/victoriametrics/changelog/CHANGELOG.md changelog primary raw.githubusercontent.com 2026-09-25
https://docs.victoriametrics.com/victoriametrics/lts-releases/ docs primary raw.githubusercontent.com 2026-09-25
https://docs.victoriametrics.com/victoriametrics/enterprise/ docs primary raw.githubusercontent.com 2026-09-25
https://github.com/VictoriaMetrics/VictoriaMetrics/releases/tag/v1.152.0 release primary web search 2026-09-25
https://docs.victoriametrics.com/victorialogs/ docs primary raw.githubusercontent.com 2026-09-25
https://docs.victoriametrics.com/victorialogs/changelog/ changelog primary raw.githubusercontent.com 2026-09-25
https://github.com/VictoriaMetrics/VictoriaLogs/releases/tag/v1.52.0 release primary web search 2026-09-25
https://docs.victoriametrics.com/victoriatraces/ docs primary raw.githubusercontent.com 2026-09-25
https://docs.victoriametrics.com/victoriatraces/changelog/ changelog primary raw.githubusercontent.com 2026-09-25
https://github.com/VictoriaMetrics/VictoriaTraces/releases/tag/v0.11.1 release primary web search 2026-09-25
https://docs.victoriametrics.com/victoriametrics/metricsql/ docs primary raw.githubusercontent.com 2026-09-25
https://docs.victoriametrics.com/operator/ docs primary raw.githubusercontent.com 2026-09-25
https://docs.victoriametrics.com/operator/changelog/ changelog primary raw.githubusercontent.com 2026-09-25
https://docs.victoriametrics.com/victoriametrics/vmagent/ docs primary raw.githubusercontent.com 2026-09-25
https://docs.victoriametrics.com/victoriametrics/vmalert/ docs primary raw.githubusercontent.com 2026-09-25
https://docs.victoriametrics.com/victoriametrics/vmauth/ docs primary raw.githubusercontent.com 2026-09-25
https://docs.victoriametrics.com/victoriametrics/vmbackup/ docs primary raw.githubusercontent.com 2026-09-25
https://docs.victoriametrics.com/victoriametrics/cluster-victoriametrics/ docs primary raw.githubusercontent.com 2026-09-25
https://docs.victoriametrics.com/victoriametrics/casestudies/ case study primary raw.githubusercontent.com 2026-09-25
https://github.com/VictoriaMetrics/prometheus-benchmark tool primary web search 2026-04-10

Secondary Sources

URL Source Kind Authority Retrieved Via Date
https://github.com/VictoriaMetrics/helm-charts repository secondary raw.githubusercontent.com 2026-09-25
https://victoriametrics.com/blog/q1-2026-whats-new-victoriametrics-cloud/ blog primary web search (title only) 2026-09-25

Community Sources

URL Source Kind Authority Retrieved Via Date
https://victoriametrics.com/blog/ blog primary web search 2026-04-10
Slack community (victoriametrics.slack.com) chat community manual 2026-04-10

Questions

Open

  • When will VictoriaTraces reach 1.0, and will the Tempo API leave "experimental"?
  • Is there an independent VictoriaLogs vs Loki benchmark at 100 GB/day or more?
  • Which release will ship vmauth browser SSO (in tip after v1.152.0)?
  • Should a standalone VictoriaLogs vs Loki comparison note be created?

Answered

  • Do they share a unified backend? — No. VictoriaMetrics, VictoriaLogs and VictoriaTraces are separate databases; VictoriaTraces is built on the VictoriaLogs storage engine but runs its own nodes. See Explanation.
  • What license is used? — Apache 2.0 for all three databases and tools (LICENSE files checked 2026-09-25); Enterprise features need a commercial license.
  • Is VictoriaMetrics a drop-in Prometheus replacement? — For storage and querying, largely yes: it accepts remote write and MetricsQL is backwards-compatible with PromQL, with documented intentional differences (no rate extrapolation, NaN removal, optional lookbehind). See Reference: MetricsQL.
  • Why is VictoriaMetrics more memory-efficient than Prometheus? — Compact TSID-sorted blocks with type-specific encodings plus ZSTD, per-partition IndexDB, caches bounded by -memory.allowedPercent, and cardinality limits. See Explanation.
  • How do companies use it at scale? — Roblox (5 billion active series), Spotify (replaced Heroic), CERN (CMS detector), Grammarly (10x cost reduction), Wix (60% infra cost reduction) per the official case studies.
  • Does VictoriaTraces require a separate VictoriaLogs cluster? — No, and it cannot share one: VictoriaTraces has its own vtinsert/vtselect/vtstorage roles (same binary, selected by flags) and embeds the VictoriaLogs engine.
  • How does LogsQL compare to LogQL on high-cardinality data? — LogsQL stores every field as a column and does not need a stream selector, so trace_id:=abc is a direct filter (bloom filters skip blocks) rather than a runtime | json parse. Keep high-cardinality fields out of _stream_fields.
  • How does Enterprise downsampling compare to Mimir's compactor? — VictoriaMetrics Enterprise -downsampling.period (for example 30d:5m,180d:1h) keeps one sample per interval for older data; Mimir's compactor merges and deduplicates blocks but does not downsample by time. Downsampling lowers fidelity to the configured interval.
  • Production gotchas for VictoriaLogs cluster above 1 TB/day? — vlinsert does not replicate (use two clusters or vlagent replication for HA); size vlstorage disks for per-day partitions; upgrade across v1.51 in the documented storage-then-select order. See How-to: VictoriaLogs upgrade.
  • vmagent vs Grafana Alloy for OTel pipelines? — vmagent is a lightweight metrics agent (scrape, relabel, stream aggregation, persistent queue); Alloy is a general OTel-based pipeline for all signals. For logs use vlagent or a shipper; for traces the OTel Collector or vtagent.
  • Trace search performance vs Tempo at 100M+ spans/day? — No independent public benchmark found (2026-09). Upstream claims up to 3.7x less RAM and 2.6x less CPU than Tempo; validate on your own workload.
  • How does vmanomaly work, and is it production-ready? — It fits models (for example Z-score, Prophet, Holt-Winters) to series, writes anomaly scores back to VictoriaMetrics for vmalert, and is managed by the operator's VMAnomaly CRD. It is an Enterprise feature.
  • Migration path from Elasticsearch to VictoriaLogs? — Point Logstash, Vector, Fluent Bit or the OTel Collector Elasticsearch exporter at /insert/elasticsearch/, map fields with _msg_field/_time_field/_stream_fields (or VL-* headers), and keep historical data in Elasticsearch until it ages out.
  • VictoriaMetrics Cloud vs Grafana Cloud pricing? — VictoriaMetrics Cloud prices by capacity tier rather than per series, which protects against cardinality spikes; the smallest VictoriaMetrics Cloud tiers start at about $190/month, other tiers are priced in the console, and egress is $0.09/GB (Cloud billing docs, checked 2026-09-27). Grafana Cloud Pro is about $6.50 per 1,000 billable series. An earlier "~$8 per series" Grafana Cloud figure was wrong (the unit is per 1,000 series) and was removed.
  • Can vmauth replace NGINX Ingress as the sole entry point? — It can terminate TLS and authenticate (Basic, Bearer, JWT/OIDC), and the operator's VMAuth CR can create an Ingress or HTTPRoute, but it is usually placed behind an ingress controller or load balancer rather than replacing it.