Skip to content

Benchmarks

Test Conditions

  • VictoriaMetrics versions: v1.136.x (stable), v1.122.x (LTS)
  • Date: April 2026
  • Note: VictoriaMetrics publishes a community benchmarking tool: prometheus-benchmark. Results below combine official benchmarks and community reports.

VictoriaMetrics vs Competitors (Metrics)

Resource Efficiency

Metric VictoriaMetrics Prometheus Thanos Mimir
RAM usage (1M active series) ~2 GB ~10–20 GB ~8–15 GB ~8–12 GB
Disk usage (compression) 0.4–1.0 bytes/sample 1.3 bytes/sample 1.5 bytes/sample 1.2–1.5 bytes/sample
Ingestion (single-node) ~1M samples/sec ~500k samples/sec N/A (sidecar) N/A (distributed)
Ingestion (cluster) 100M+ samples/sec N/A ~50M+ 30M+
Query latency (simple PromQL) < 100ms < 100ms (local) Variable (ObjStore) < 200ms

Key Findings

  • RAM: VictoriaMetrics consistently uses 5–10x less RAM than Prometheus for the same workload due to aggressive memory management and ZSTD compression
  • Disk: ~50% less disk than Prometheus, due to specialized ZSTD + delta-encoding for floats/timestamps
  • Cardinality resilience: VM handles high-cardinality spikes more gracefully via -memory.allowedPercent, while Prometheus OOM-kills

Production Scale Records

Company Scale Notes
Roblox Billions of active series 100% uptime across quarters
DreamHost 76M active series 80% memory reduction vs previous stack
Grammarly Large-scale metrics 10x cost reduction
CERN CMS detector monitoring Long-term Prometheus storage

VictoriaLogs Benchmarks

Metric VictoriaLogs Loki Elasticsearch
Storage efficiency 10–30x less disk than ES 10–20x less than ES Baseline
RAM usage Minimal (bloom filters, no inverted index) Low (label-only index) High (inverted index)
Ingestion Very high (columnar, batch writes) High Moderate (indexing overhead)
Query (filtered) Sub-second Sub-second Sub-second
Query (full scan) Depends on bloom filter selectivity Depends on label cardinality Fast (full-text index)
Full-text search ✅ (via bloom filters) ❌ (label-first) ✅ (inverted index)

Key advantage: VictoriaLogs allows free-text search WITHOUT mandatory label selectors, unlike Loki which requires {label="value"} first.

VictoriaTraces Benchmarks

Metric VictoriaTraces Tempo Jaeger + ES
Storage Local disk (columnar + bloom) Object storage (Parquet) Elasticsearch cluster
External deps None S3/GCS required ES cluster required
RAM usage Low Low High
Trace ID lookup Fast < 200ms Fast
Search Bloom-filter-based Parquet column scan Full-text index
Operational overhead Very low (single binary) Low-moderate High

Cost Comparison: Victoria Stack vs LGTM vs Datadog

At 1M Active Series + 100 GB/day Logs + 50M Spans/day

Stack Est. Monthly Cost RAM Footprint Disk Footprint Ops Burden
Victoria Stack (self-hosted) $500–1,500 Lowest Lowest Low
Self-hosted LGTM $1,000–3,000 Medium Medium High
Grafana Cloud Pro $1,500–4,000 N/A (managed) N/A Low
VM Cloud (single-node) $225–1,300 N/A (managed) N/A Very Low
Datadog $5,000–17,000 N/A (SaaS) N/A Very Low

Victoria Stack is typically 2–3x cheaper than LGTM due to lower resource footprint and no object storage costs.

Caveats

  • Benchmarks heavily depend on "data shape" — active series churn rate, label cardinality, and query density
  • VictoriaMetrics' RAM savings are most dramatic at high cardinality (> 1M active series)
  • VictoriaLogs bloom-filter approach trades slightly higher CPU for dramatically lower RAM vs inverted indexes
  • VictoriaTraces is newer and has fewer large-scale public benchmarks than Tempo
  • Local SSD storage means you trade object storage durability for latency — use vmbackup to S3 for DR
  • Run prometheus-benchmark on YOUR workload before making migration decisions

Sources

URL Source Kind Authority Date
https://docs.victoriametrics.com/ docs primary 2026-04-10
https://github.com/VictoriaMetrics/prometheus-benchmark tool primary 2026-04-10
https://victoriametrics.com/case-studies/ case study primary 2026-04-10