Skip to content

LGTM Stack vs Victoria Stack

Summary

A head-to-head comparison of the two composable open-source observability stacks in this vault: Grafana Labs' LGTM Stack (Loki, Grafana, Tempo, Mimir, plus Pyroscope and Alloy, AGPL-3.0 backends) and the Victoria Stack (VictoriaMetrics, VictoriaLogs, VictoriaTraces and their agents, Apache-2.0). LGTM puts every signal on object storage and, since 2025-2026, puts Kafka in the write path of Mimir and Tempo at scale. Victoria runs single binaries on local disks with no external dependencies. Versions and features match the topic pages as of 2026-09-25. Performance and cost figures are vendor claims or rough, unsourced estimates and are labelled as such.

Which One Should I Pick?

The flowchart gives a first cut. The sections below explain each question.

flowchart TD
    Q1{"Need continuous profiling<br/>in the same stack?"}
    Q2{"Need production-grade trace search<br/>(full TraceQL, span metrics) today?"}
    Q3{"Is infrastructure cost or<br/>operational simplicity the top priority?"}
    Q4{"Do you have a platform team that can run<br/>many components plus Kafka?"}
    Q5{"Does AGPL-3.0 cause compliance issues<br/>(for example, you ship a SaaS on modified code)?"}
    Q6{"Need long retention on object storage<br/>rather than local disks?"}
    LGTM["LGTM Stack<br/>(Pyroscope, Tempo 3, Mimir 3)"]
    VM["Victoria Stack<br/>(VictoriaMetrics, VictoriaLogs)"]
    HYB["Hybrid: Victoria for metrics and logs,<br/>Tempo for traces, Grafana on top"]

    Q1 -->|"Yes"| LGTM
    Q1 -->|"No"| Q2
    Q2 -->|"Yes"| HYB
    Q2 -->|"No"| Q3
    Q3 -->|"Yes"| VM
    Q3 -->|"No"| Q4
    Q4 -->|"No"| VM
    Q4 -->|"Yes"| Q5
    Q5 -->|"Yes"| VM
    Q5 -->|"No"| Q6
    Q6 -->|"Yes"| LGTM
    Q6 -->|"No"| VM

TL;DR

LGTM Stack Victoria Stack
Philosophy Composable microservices, object-storage-first, Grafana-integrated Efficiency-first single binaries, local disks, no external dependencies
Best for Large organizations with platform teams and deep cross-signal correlation needs Cost-conscious teams that want low resource use and low operational burden
License AGPL-3.0 backends and Grafana; Alloy Apache-2.0 Apache-2.0; Enterprise features commercial
Main gap Operational complexity (many components, Kafka at scale) No profiling; VictoriaTraces is still pre-1.0

Versions and Compatibility (2026-09-25)

Latest Versions

Role LGTM component LGTM version (date) Victoria component Victoria version (date)
Metrics Grafana Mimir 3.2.1 (2026-09-10) VictoriaMetrics v1.152.0 (2026-09-14)
Logs Grafana Loki 3.7.8 (2026-09-17) VictoriaLogs v1.52.0 (2026-07-16)
Traces Grafana Tempo 3.0.3 (2026-08-13); 3.1.0-rc.1 VictoriaTraces v0.11.1 (2026-09-16), pre-1.0
Profiles Grafana Pyroscope 2.3.1 (2026-09-08) None —
Visualization Grafana 13.2.2 (2026-09-15) Grafana + VMUI Same Grafana
Collection Grafana Alloy 1.20.0 (2026-09-25) vmagent, vlagent, vtagent vmagent ships with VictoriaMetrics
Routing / auth Your own gateway (Ingress, reverse proxy) — vmauth Ships with VictoriaMetrics
Kubernetes Per-component Helm charts; Loki and Tempo Operators (OpenShift-focused) — VictoriaMetrics Operator v0.74.1 (2026-08-04)

Victoria also publishes Enterprise LTS lines (v1.148.x and v1.136.x as of 2026-09). LGTM keeps security patches on previous minors. Full matrices: LGTM reference and Victoria reference.

Maturity

Signal LGTM Victoria
Metrics Production. Mimir 3.x (Cortex lineage); ingest storage (Kafka) preferred since 3.0 Production. VictoriaMetrics 1.x, case studies at Roblox, Spotify, CERN
Logs Production. Loki 3.7; Simple Scalable mode deprecated, removal planned for 4.0 Production. VictoriaLogs GA since v1.0.0 (2024-11-12)
Traces Production. Tempo 3.0 GA 2026-05-28 (new block-builder and live-store architecture) Pre-1.0. VictoriaTraces 0.x since 2025-07
Profiles Production. Pyroscope 2.x (object-storage write path) Not available

Ingestion Protocols

Protocol LGTM Victoria
OTLP Every backend accepts OTLP natively; Alloy can front them OTLP/HTTP on all three databases; OTLP/gRPC on VictoriaTraces when enabled
Prometheus remote_write Mimir VictoriaMetrics and vmagent
Prometheus scrape Alloy, Prometheus agent mode vmagent (drop-in replacement)
InfluxDB, Graphite, OpenTSDB, Datadog, NewRelic No (Alloy components can convert some) VictoriaMetrics
Loki push API Loki VictoriaLogs (/insert/loki/api/v1/push)
Elasticsearch _bulk No VictoriaLogs
Syslog, journald Via Alloy (Promtail was removed in Loki 3.7.3) VictoriaLogs (native)
JSON lines Via Alloy pipeline VictoriaLogs (/insert/jsonline)
Jaeger, Zipkin Tempo No. VictoriaTraces is OTLP-only; put an OpenTelemetry Collector in front
Profiles (pprof push) Pyroscope No

Verdict: Victoria accepts more metric and log formats natively (InfluxDB, Graphite, Datadog, NewRelic, Elasticsearch bulk). LGTM accepts more trace formats (Jaeger, Zipkin) and is the only one with profiles.

Query APIs

API LGTM Victoria
Prometheus query API (/api/v1/query) Mimir VictoriaMetrics (MetricsQL, PromQL-compatible with intentional differences)
Loki query API (/loki/api/v1/query) Loki No (VictoriaLogs uses /select/logsql/query)
Jaeger query API Via Grafana's Jaeger data source against other backends VictoriaTraces at /select/jaeger
Tempo API / TraceQL Tempo (full TraceQL and TraceQL metrics) VictoriaTraces at /select/tempo, experimental, TraceQL subset
Grafana data sources Native data source per backend Prometheus (or VictoriaMetrics plugin), VictoriaLogs plugin, Jaeger or Tempo

Platform Requirements

Requirement LGTM Victoria
Kubernetes Recommended; mimir-distributed 6.x needs 1.29+ Optional; operator or Helm charts
Object storage Required in production for Mimir, Loki, Tempo, Pyroscope Not required (optional backup target)
Kafka-compatible log Mimir ingest storage (preferred; Helm default) and Tempo 3 microservices (required) Not required
Caches Memcached recommended (Mimir 3 removed Redis; Loki and Tempo still accept Redis) Built-in caches
Grafana database PostgreSQL or MySQL for HA (SQLite is dev-only) Same, if you run Grafana
Local disks Ingester and live-store state, caches Required for all storage nodes (SSD recommended)
Prod RAM at 1M active series Mimir ingesters alone need about 25 GB at RF=3 (2.5 GB per 300,000 in-memory series), plus distributors, queriers, store-gateways and caches (Mimir capacity planning) Not published: VictoriaMetrics says to size from a test run and keep 50% free RAM (capacity planning)

Object Storage Support (LGTM)

Provider Mimir Loki Tempo Pyroscope
AWS S3 and S3-compatible (MinIO) Yes Yes Yes Yes
Google Cloud Storage Yes Yes Yes Yes
Azure Blob Storage Yes Yes Yes Yes
OpenStack Swift Yes Yes (swift_storage_config) No Yes (swift backend)

Upgrade Considerations (2026-09)

Component Notes
Mimir 3.x Ingest storage (Kafka) is the preferred architecture; query-scheduler required; Redis cache and read-write mode removed in 3.0
Loki 3.7 Helm chart moved to grafana-community/helm-charts (default deploymentMode: Monolithic); Promtail removed in 3.7.3; Simple Scalable deprecated. Loki 3.8 (unreleased) will remove BoltDB, Cassandra, DynamoDB, BigTable and gRPC stores
Tempo 3.0 Ingesters and compactors replaced by block-builders, live-stores and backend scheduler/workers; Kafka required in microservices mode; no downgrade; vParquet3 writes refused in 3.1
Pyroscope 2.x v2 storage (segment-writer, metastore) is the default; diskless write path
VictoriaMetrics 1.15x Rolling releases about every two weeks; tenant-in-headers default on since v1.150.0; Enterprise LTS lines for conservative environments
VictoriaLogs 1.5x v1.51.1 is an upgrade-bridge patch; images distroless since v1.52.0
VictoriaTraces 0.x Pre-1.0; experimental Tempo API; vtagent OTLP forwarder since v0.11.0

Component Mapping

Signal LGTM Victoria Notes
Metrics Mimir VictoriaMetrics Both PromQL-compatible; MetricsQL adds extensions and fixes rate/increase edge cases
Logs Loki VictoriaLogs Loki indexes stream labels only; VictoriaLogs stores every field as a column with per-block bloom filters
Traces Tempo VictoriaTraces Tempo: Parquet on object storage, TraceQL. VictoriaTraces: spans stored as log entries on the VictoriaLogs engine, sharded by trace ID
Profiles Pyroscope None Victoria has no profiling component
Visualization Grafana Grafana + VMUI VMUI is a lightweight built-in UI
Collection Alloy (OpenTelemetry Collector distribution) vmagent, vlagent, OTel Collector Grafana Agent and Promtail are retired
Alerting Grafana Alerting, Mimir and Loki rulers vmalert + Alertmanager vmalert evaluates MetricsQL, LogsQL and trace rules
Routing / auth Your own gateway setting X-Scope-OrgID vmauth (one proxy for all three databases)
Backup Data already on object storage vmbackup (metrics); partition snapshots (logs, traces)
Kubernetes Helm charts (two repositories since 2026), Jsonnet VictoriaMetrics Operator CRDs (VMCluster, VLCluster, VTCluster and more)

Architecture Comparison

The diagram shows each stack's write and read paths with real component names. Kafka appears in LGTM's path because Mimir ingest storage and Tempo 3 microservices use it.

flowchart LR
    subgraph LGTM["LGTM Stack"]
        direction TB
        LA["Grafana Alloy"]
        LK["Kafka-compatible log"]
        LM["Mimir (metrics)"]
        LL["Loki (logs)"]
        LT["Tempo (traces)"]
        LP["Pyroscope (profiles)"]
        LOS[("Object storage")]
        LG["Grafana"]
        LA --> LL
        LA --> LP
        LA -->|"ingest storage"| LK
        LK --> LM
        LK --> LT
        LM --> LOS
        LL --> LOS
        LT --> LOS
        LP --> LOS
        LG -.-> LM
        LG -.-> LL
        LG -.-> LT
        LG -.-> LP
    end

    subgraph VIC["Victoria Stack"]
        direction TB
        VA["vmagent / vlagent /<br/>OTel Collector"]
        VAU["vmauth"]
        VMM["VictoriaMetrics"]
        VLL["VictoriaLogs"]
        VTT["VictoriaTraces<br/>(VictoriaLogs engine)"]
        VD[("Local disks")]
        VG["Grafana / VMUI"]
        VA --> VAU
        VAU --> VMM
        VAU --> VLL
        VAU --> VTT
        VMM --> VD
        VLL --> VD
        VTT --> VD
        VG -.-> VAU
    end

Key Architectural Differences

Dimension LGTM Victoria
Storage backend Object storage, mandatory in production Local disks, no external dependencies
Cluster design Microservices with many roles per backend (distributor, ingester or block-builder, querier, store-gateway, compactor and more) Shared-nothing insert/select/storage roles per database
Component communication gRPC, hash rings over memberlist, Kafka partitions Consistent hashing from insert nodes; storage nodes do not talk to each other
Caching Memcached recommended for production query performance Built-in caches
Durability on crash Ingester WAL (classic) or the Kafka log (ingest storage, Tempo 3) No WAL by design: seconds of unflushed data can be lost; senders (vmagent on-disk queue) retry
External dependencies Object storage, Kafka at scale, Memcached, Grafana database None

Feature-by-Feature Comparison

Metrics

Feature Mimir VictoriaMetrics
Query language PromQL (Mimir Query Engine default since 3.0) MetricsQL (PromQL-compatible with intentional differences)
Multi-tenancy X-Scope-OrgID header, on by default accountID:projectID in URL path or headers (cluster only)
Replication RF=3 in classic mode; Kafka partitions in ingest storage -replicationFactor=N on vminsert; needs 2*N-1 vmstorage nodes
HA Prometheus dedup Built in -dedup.minScrapeInterval
Long-term storage Object storage, effectively unbounded Local disks, bounded by capacity
Downsampling Not supported (use recording rules) Enterprise only
Recording rules Mimir ruler vmalert
Exemplars Stored Not stored (open feature request)
Scale on record 1B+ active series (Grafana Labs load test, 2022) 5 billion active series (Roblox case study)
RAM per 1M active series About 25 GB for ingesters at RF=3 (Mimir capacity planning) Not published (size by test run)
Disk per sample Capacity planning assumes 2 bytes per sample in compacted blocks 0.4-1.75 bytes in official case studies

Verdict: VictoriaMetrics case studies report lower RAM and disk use than the Prometheus-based systems they replaced (for example DreamHost: 80% less memory), but no neutral per-series comparison is published. Mimir wins on object-storage retention, exemplars and tenant isolation.

Logs

Feature Loki VictoriaLogs
Indexing Stream labels only; structured metadata for high-cardinality fields; experimental bloom components Every field stored as a column; bloom filters per block
Full-text search Needs a stream selector first, then line scan Free-text search without a selector
Query language LogQL LogsQL
Example {app="api"} \|= "error" _time:5m error
Multi-tenancy X-Scope-OrgID, on by default AccountID/ProjectID headers
Storage Object storage (chunks + TSDB index) Local disk, per-day partitions
Replication Ingester RF=3 None in-cluster; write to two clusters for HA
Ingestion APIs Loki push, OTLP Loki push, Elasticsearch bulk, OTLP, syslog, journald, JSON lines
Resource claim — Up to 30x less RAM and 15x less disk than Elasticsearch and Loki (vendor claim)

Verdict: VictoriaLogs wins on resource use (vendor claim), free-text search and ingestion breadth. Loki wins on ecosystem maturity and object-storage durability.

Traces

Feature Tempo VictoriaTraces
Storage Apache Parquet blocks on object storage Local disk on the VictoriaLogs engine
Index None; trace-ID sharding, bloom filters, Parquet columns Columnar fields with bloom filters
Query TraceQL, structural operators, TraceQL metrics (GA in 3.0) Jaeger query API, LogsQL over spans, experimental Tempo API (TraceQL subset)
Span metrics and service graph Tempo metrics-generator Service-graph relations (0.x)
Ingestion OTLP, Jaeger, Zipkin OTLP only
Grafana Native Tempo data source Jaeger data source, or Tempo data source (experimental)
Maturity Tempo 3.0 GA (2026-05) Pre-1.0
External dependencies Object storage; Kafka in microservices mode None
Resource claim — Up to 3.7x less RAM and 2.6x less CPU than Tempo (vendor claim)

Verdict: Tempo wins on query power (TraceQL), span metrics and maturity. VictoriaTraces wins on simplicity and claimed resource use, and its experimental Tempo API lets Grafana's Tempo data source do basic search.

Profiles

Feature Pyroscope Victoria Stack
Continuous profiling Yes, flame graphs and Profiles Drilldown No profiling component
Query Label selectors per profile type (the old Pyroscope "FlameQL" name is no longer used in Grafana docs) —
Trace to profiles Integrated with Tempo in Grafana —

Verdict: only LGTM covers profiles. A Victoria user who needs profiles can run Pyroscope alongside it.

Cross-Signal Correlation

Correlation LGTM Victoria
Metrics to traces (exemplars) Native (Mimir exemplars to Tempo) No exemplar storage; use Grafana correlations instead
Traces to logs Native (Tempo trace-to-logs) Manual Grafana configuration
Logs to traces (derived fields) Native (Loki derived fields to Tempo) Manual Grafana configuration
Traces to metrics Native Not built in
Traces to profiles Native No profiling
Span metrics Automatic (Tempo metrics-generator) Not available

Verdict: LGTM has much better cross-signal correlation because Grafana's data sources are built for it.

Operational Comparison

Dimension LGTM Victoria
Minimum production pods ~20+ across backends (estimate) ~5-10 (estimate)
External dependencies Object storage, Kafka at scale, Memcached, Grafana database None
Helm charts One per component, split across grafana and grafana-community repositories; lgtm-distributed umbrella deprecated victoria-metrics-k8s-stack or per-component charts; operator manages the rest
Kubernetes operator None for the full stack; Loki and Tempo Operators (OpenShift-focused) VictoriaMetrics Operator with CRDs for all three databases
Configuration Per-component YAML and Helm values CLI flags; one vmauth config
Upgrades Rolling per component; breaking majors (Mimir 3, Tempo 3, Pyroscope 2, Loki 4 ahead) Rolling; Enterprise LTS lines
Backup Inherent (object storage) Schedule vmbackup and snapshots
Monitoring the monitoring Mixins (mimir-mixin, loki-mixin, tempo-mixin) Self-scraped /metrics

Performance Comparison

No independent benchmark compares the two stacks end to end. The figures below are vendor figures or carried-over estimates; see the LGTM scale figures and Victoria benchmarks for their provenance.

Ingestion Throughput

Signal LGTM Victoria
Metrics, single node Monolithic Mimir exists; no published ceiling Up to 2M samples/s and 100M active series in real use (FAQ); cluster docs suggest single-node below about 1M samples/s
Metrics, cluster About 50M samples/s at 1B active series (Grafana Labs load test) 120M data points/s on 200 vmstorage nodes (Roblox case study); FAQ says "hundreds of millions of samples per second"
Logs Monolithic about 20 GB/day guideline; official sizing tiers up to about 30 TB/day per cluster (Loki sizing) No published figure
Traces Tempo monolithic 25-35 MB/s or 55k-80k spans/s (Tempo 3 docs) No published figure
Profiles Pyroscope v2 median ingest latency below 500 ms Not applicable

Query Behavior

Query type Where each stack is stronger
Recent metrics Comparable; both serve recent data from memory or local disk
Long-range metrics (30 days) Victoria reads local disk; LGTM depends on object storage and Memcached hit rate
High-cardinality metrics VictoriaMetrics is reported to degrade less because of lower per-series RAM
Label-filtered log search Comparable when labels narrow the scope
Full-text log search VictoriaLogs only; Loki needs a stream selector
Trace-ID lookup Comparable
Trace attribute search Tempo (TraceQL) is richer

Verdict: Victoria is reported to be more resource-efficient because it avoids object-storage round-trips and coordination. LGTM trades that for durability and unbounded retention.

Reliability Comparison

High Availability

Dimension LGTM Victoria
Metrics replication RF=3 (classic) or Kafka (ingest storage), automatic -replicationFactor=N on vminsert; configure explicitly
Logs and traces replication Loki ingester RF=3; Tempo via Kafka and zone-aware live-stores None in-cluster; run two clusters and write to both
Durability Object storage Local disks + vmbackup
Storage node failure Data in object storage; replicas serve recent data With RF=1 that shard is unavailable until the node returns or is restored; RF=N tolerates N-1 failures
Graceful degradation Query-frontend splits and retries vmselect returns partial responses; vlselect returns 502 for failover
Crash recovery WAL replay or Kafka replay No WAL; seconds of unflushed data lost, senders retry

Disaster Recovery

Dimension LGTM Victoria
RPO Near zero for data already in object storage Depends on backup schedule, unless replicated
RTO Minutes (new pods read object storage) Minutes to hours (restore from backup)
Cross-region DR Object storage replication vmbackup to a remote bucket
Backup effort None beyond bucket policy Schedule vmbackup (vmbackupmanager is Enterprise)

Failure Modes

Scenario LGTM impact Victoria impact
One ingester or storage node dies No data loss with replication Gaps if RF=1; partial results if RF>=2
Object storage outage Historical queries fail; recent data still served No impact
Kafka outage Writes to Mimir (ingest storage) and Tempo 3 microservices back up or fail No impact
Memcached down Query latency degrades No impact
Grafana database down Dashboards and users unavailable Same if you run Grafana; VMUI unaffected
Full AZ outage Data survives in object storage Local data in that AZ unavailable

Verdict: LGTM wins on durability. Victoria wins on operational resilience (fewer dependencies that can fail). Victoria users must plan replication and backups.

Scalability Comparison

Dimension LGTM Victoria
Horizontal scaling Per component (distributors, ingesters, queriers, store-gateways, block-builders) Per role (vminsert, vmselect, vmstorage)
Vertical scaling Microservices prefer horizontal Single node handles about 1M samples/s
Scale on record Mimir 1B+ active series (2022 test) Roblox 5 billion active series
Storage capacity Object storage, effectively unbounded Sum of local disks
Tenant isolation X-Scope-OrgID with per-tenant limits Tenant IDs in path or headers; per-tenant statistics are Enterprise
Adding capacity Add pods; object storage grows by itself Add vmstorage nodes (rerouting spreads load since v1.149.0)

Security Comparison

Dimension LGTM Victoria
Authentication Backends expect an auth gateway in OSS; Grafana handles users vmauth: Basic, Bearer, JWT/OIDC (v1.137+); vmgateway in Enterprise
Authorization Grafana roles; fine-grained RBAC in Enterprise/Cloud vmauth routing rules; no RBAC UI
SSO Grafana OAuth/OIDC and LDAP; SAML in Enterprise/Cloud vmauth OIDC; browser SSO only in unreleased tip (2026-09)
Multi-tenancy X-Scope-OrgID enforced by backends Tenant IDs enforced by vmauth routing
Encryption at rest Object storage encryption (SSE-S3, SSE-KMS) Disk encryption (LUKS, dm-crypt)
Encryption in transit TLS configurable per component TLS; mTLS between components is Enterprise-only
Audit logging Grafana Enterprise Not built in

Verdict: LGTM wins on enterprise security features through Grafana's access control. Victoria's vmauth is simpler but coarser.

Developer Experience Comparison

Query Languages

Aspect LGTM Victoria
Metrics PromQL MetricsQL (fixes extrapolation, adds keep_metric_names and more)
Logs LogQL (stream selector required) LogsQL (no mandatory selector)
Traces TraceQL Jaeger API, LogsQL, experimental TraceQL subset
Profiles Label selectors per profile type —
Learning curve Four query models Two languages plus the Jaeger API
Query builder UI Grafana builders and Drilldown apps VMUI; Grafana builders via data sources

Instrumentation and Onboarding

Aspect LGTM Victoria
Recommended collector Alloy vmagent (metrics), vlagent (logs), OTel Collector
Auto-instrumentation OTel agents, Beyla/OBI via Alloy Same OTel agents
Dashboard portability Grafana JSON Same Grafana JSON (MetricsQL-only functions need rewriting when leaving)
Getting started docker run grafana/otel-lgtm (all-in-one dev image) docker run victoriametrics/victoria-metrics (per component)
Playground play.grafana.org No public playground listed in the topic page
Documentation Extensive, per component Thorough flag-level docs, fewer architecture guides

Verdict: LGTM wins on onboarding and trace query power. Victoria wins on protocol breadth and MetricsQL's practical fixes.

Community and Ecosystem

Dimension LGTM Victoria
GitHub stars (2026-04 snapshot) ~120k combined (Grafana ~73k, Loki ~28k, Pyroscope ~10k, Mimir ~5k, Tempo ~4k) ~16.7k (main repo)
Release cadence Mimir minors about quarterly; Loki minors about quarterly; Tempo, Pyroscope, Alloy every 1-2 months VictoriaMetrics about every 2 weeks; VictoriaLogs and VictoriaTraces about monthly; Enterprise LTS
Plugins 100+ Grafana data-source plugins Uses Grafana's ecosystem
Commercial backing Grafana Labs: $400M+ ARR (2025-09); reportedly raising at about $9B valuation (2026-02) VictoriaMetrics, Inc.
Support Grafana Enterprise, Grafana Cloud VictoriaMetrics Enterprise, VictoriaMetrics Cloud
Managed cloud Grafana Cloud: Free tier (10k series, 50 GB each of logs, traces, profiles), Pro $19/month + usage VictoriaMetrics Cloud: metrics, logs (since Q1 2026) and traces tiers; smallest tiers from about $190/month
Case studies Maersk (ObservabilityCON 2023), DHL Express Switzerland, Salesforce (GrafanaCONline 2021); see LGTM Stack Roblox, Spotify, CERN, Grammarly, Wix, adidas; DreamHost (blog)

Verdict: LGTM wins on ecosystem breadth, community size and hiring. Victoria has a smaller, focused team.

Scorecard

Scores (1 to 5) are editorial judgments derived from the tables above, not measurements.

Aspect LGTM Victoria Leader
Throughput per resource 3 5 Victoria
Resource efficiency 3 5 Victoria
Data durability 5 3 LGTM
Operational resilience 3 5 Victoria
Scalability 5 4 LGTM
Cross-signal correlation 5 2 LGTM
Security and RBAC 5 3 LGTM
Operational simplicity 2 5 Victoria
Cost (estimates) 3 5 Victoria
Developer experience 5 4 LGTM
Community and ecosystem 5 3 LGTM
Licensing flexibility 3 5 Victoria
Signal coverage 5 (with profiles) 3 (no profiles, traces 0.x) LGTM

Cost Comparison

Self-Hosted at 1M Active Series, 100 GB/day Logs, 50M Spans/day

The self-hosted rows are illustrative, unsourced figures carried in the topic reference pages (LGTM, Victoria); the Grafana Cloud row is computed from list prices (2026-09-27). They exclude staff time and Enterprise licenses.

Stack Estimated monthly infrastructure Main drivers
LGTM (self-hosted) $1,000-3,000 20+ pods, object storage requests, Kafka, Memcached, Grafana database
Victoria (self-hosted) $500-1,500 Fewer pods, local SSDs, backups
Grafana Cloud Pro About $7,600+ at list price (about $6,400 for 1M billable series plus about $1,200-1,300 of logs; traces extra), before discounts or Adaptive Metrics Usage-based (about $6.50 per 1,000 series above the free tier)

Victoria is usually estimated at roughly half the self-hosted infrastructure cost, mainly because it runs fewer pods, needs no object storage requests or caches, and uses less RAM.

Managed Services

Grafana Cloud Pro VictoriaMetrics Cloud
Starting price $19/month + usage About $190/month for the smallest tiers; other tier prices only in the Cloud console (billing docs, checked 2026-09-27)
Free tier Yes (10k series; 50 GB logs, traces, profiles) Trial: $200 of credits for 30 days
Pricing basis Per active series and per GB Capacity tiers (series, churn, ingestion rate)
Signals Metrics, logs, traces, profiles Metrics, logs (since Q1 2026) and traces

Licensing Comparison

LGTM Victoria
Core license AGPL-3.0 (Grafana, Loki, Tempo relicensed from Apache-2.0 in 2021; Mimir AGPL since 2022) Apache-2.0
SaaS implications Modifying the code and offering it over a network requires publishing the changes No copyleft obligations
Enterprise editions Grafana Enterprise, GEM, GEL, GET VictoriaMetrics Enterprise (downsampling, retention filters, mTLS, vmgateway, vmanomaly, LTS)
Collectors Alloy: Apache-2.0 vmagent: Apache-2.0
Unmodified self-hosting No obligations No obligations

Migration Paths

From LGTM to Victoria

Signal Strategy Difficulty
Metrics Add a remote_write to VictoriaMetrics alongside Mimir, dual-write, then cut over Easy
Logs Point Alloy, Fluent Bit or Vector at VictoriaLogs (Loki push API accepted) Easy
Traces Re-point OTLP exporters to VictoriaTraces; Jaeger and Zipkin clients need an OTel Collector in front Easy to medium
Dashboards PromQL dashboards keep working; LogQL and TraceQL panels need rewriting Low to medium
Alerts Port Mimir ruler rules to vmalert (same PromQL) Low
Profiles No Victoria equivalent; keep Pyroscope —

From Victoria to LGTM

Signal Strategy Difficulty
Metrics Add remote_write to Mimir, dual-write Easy
Logs Point shippers at Loki; design stream labels first Easy to medium
Traces Re-point OTLP exporters to Tempo Easy
Dashboards MetricsQL-only functions and LogsQL panels need conversion Low to medium
Alerts vmalert rules are mostly PromQL-compatible Low

Choose LGTM When

  • You need continuous profiling (Pyroscope) or mature trace search (TraceQL, span metrics).
  • Deep cross-signal correlation (exemplars, trace-to-logs, trace-to-profiles) is critical.
  • You want retention on object storage with little backup work.
  • You have a platform team that can run many components plus Kafka.
  • You want a managed option with a free tier (Grafana Cloud).

Choose Victoria Stack When

  • Cost efficiency and operational simplicity are top priorities.
  • Apache-2.0 matters (for example, you build a SaaS on modified code).
  • You need high cardinality metrics with low RAM, or many metric formats (InfluxDB, Graphite, Datadog).
  • You want full-text log search without mandatory stream selectors.
  • You want a Kubernetes operator that manages all three databases.

Hybrid Approach

Many organizations mix components, with Grafana on top regardless of backend:

  • VictoriaMetrics for metrics + Loki for logs + Tempo for traces.
  • VictoriaMetrics + VictoriaLogs + Tempo (keeps TraceQL and span metrics).
  • Victoria for metrics and logs + Pyroscope for profiles.

Sources

Most facts come from the linked topic pages (researched 2026-09-25), which cite primary sources.

URL Source kind Authority Date
https://docs.victoriametrics.com/ docs primary 2026-09-25
https://docs.victoriametrics.com/victoriatraces/data-ingestion/ docs (VictoriaTraces is OTLP-only) primary 2026-09-25
https://docs.victoriametrics.com/victoriametrics/enterprise/ docs (Enterprise features) primary 2026-09-25
https://docs.victoriametrics.com/victoriametrics/casestudies/ case studies primary 2026-09-25
https://github.com/VictoriaMetrics/VictoriaMetrics/issues/1169 issue (exemplar storage not supported) primary 2026-09-25
https://grafana.com/docs/ docs primary 2026-09-25
https://grafana.com/docs/tempo/latest/release-notes/v3-0/ release notes primary 2026-09-25
https://grafana.com/blog/grafana-mimir-3-0-release-all-the-latest-updates/ release blog primary 2026-09-25
https://github.com/grafana/mimir/pull/3024 pull request (downsampling code removed) primary 2026-09-25
https://grafana.com/pricing/ pricing primary 2026-09-25
https://grafana.com/press/2025/09/30/grafana-labs-surpasses-400m-arr-and-7000-customers-gains-new-investors-to-accelerate-global-expansion/ press release primary 2026-09-25
https://siliconangle.com/2026/02/13/grafana-labs-reportedly-raising-funding-9b-valuation/ news secondary 2026-09-25