Grafana Mimir and VictoriaMetrics - Long-Term Storage Beyond Thanos and Cortex

by Bala

Deploying Mimir and VictoriaMetrics cluster mode for scalable, long-term Prometheus storage, and how they compare to Thanos and Cortex

Introduction

The Thanos and Cortex guides on this site cover the two earlier entrants in the “scale Prometheus beyond a single node’s retention and cardinality limits” space. Grafana Mimir and VictoriaMetrics are the two systems most commonly evaluated alongside them today - Mimir as Grafana Labs’ own evolution of the same ideas Cortex pioneered, VictoriaMetrics as a from-scratch, storage-efficiency-focused alternative. This guide covers deploying both and where each fits relative to Thanos/Cortex.

Grafana Mimir

Mimir is built by Grafana Labs (several of Cortex’s original authors now work on Mimir) and shares Cortex’s core architecture - horizontally scalable, multi-tenant, object-storage-backed - while focused on higher cardinality limits and lower operational overhead than Cortex in practice. It ships as a single binary capable of running in monolithic mode (all components in one process, for smaller deployments) or split into per-component microservices (distributor, ingester, querier, compactor, store-gateway) for independent scaling at real production volume.

helm repo add grafana https://grafana.github.io/helm-charts
helm repo update

helm install mimir grafana/mimir-distributed \
  --namespace monitoring \
  --set mimir.structuredConfig.limits.max_global_series_per_user=1000000
# values.yaml (monolithic mode - simplest starting point)
deploymentMode: SingleBinary

minio:
  enabled: true   # use the chart's bundled MinIO for object storage, or point at real S3/GCS/Azure Blob

singleBinary:
  replicas: 3

Pointing Prometheus (or an OTel Collector / Grafana Alloy) at Mimir is the same remote-write mechanism Thanos and Cortex use:

# prometheus.yml
remote_write:
  - url: http://mimir-nginx.monitoring.svc:80/api/v1/push
    headers:
      X-Scope-OrgID: tenant-a   # required once multi-tenancy is enabled

X-Scope-OrgID is Mimir’s (and Cortex’s) tenant-isolation header - every write and query must carry it once multi-tenancy is turned on, and each tenant’s data is fully isolated in storage and queries, the mechanism that makes a single Mimir deployment usable as shared infrastructure across many teams or clusters safely.

Querying is the standard Prometheus-compatible API, so a Grafana datasource pointed at Mimir’s query endpoint works exactly like pointing it at Prometheus directly - existing dashboards and alerting rules need no PromQL changes to work against Mimir.

VictoriaMetrics

VictoriaMetrics takes a different approach: a from-scratch storage engine (not built on Prometheus’s TSDB code, unlike Thanos/Cortex/Mimir) optimized specifically for storage efficiency and query speed, commonly reported to use significantly less disk and memory than Prometheus’s own TSDB or Cortex/Mimir for the same data volume. It’s available as a single binary (victoria-metrics, fine for small-to-medium scale) or a cluster (vminsert/vmstorage/vmselect, for horizontal scale):

helm repo add vm https://victoriametrics.github.io/helm-charts/
helm repo update

helm install vmcluster vm/victoria-metrics-cluster \
  --namespace monitoring \
  --set vminsert.replicaCount=2 \
  --set vmstorage.replicaCount=3 \
  --set vmselect.replicaCount=2
# prometheus.yml
remote_write:
  - url: http://vminsert-vmcluster.monitoring.svc:8480/insert/0/prometheus/

vminsert accepts writes and distributes them across vmstorage nodes; vmselect serves queries by fanning out across the same vmstorage nodes and merging results - the 0 in the insert URL path is the tenant/account ID in cluster mode’s multi-tenancy scheme, analogous to Mimir’s X-Scope-OrgID header but expressed in the URL path instead.

VictoriaMetrics also ships vmagent, a lightweight alternative to running full Prometheus purely for scraping-and-forwarding - useful when you want remote-write behavior (service discovery, relabeling, scraping) without a local TSDB or local alerting evaluation at all:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: vmagent
spec:
  template:
    spec:
      containers:
        - name: vmagent
          image: victoriametrics/vmagent:latest
          args:
            - -promscrape.config=/etc/vmagent/scrape.yaml
            - -remoteWrite.url=http://vminsert-vmcluster.monitoring.svc:8480/insert/0/prometheus/

VictoriaMetrics is queried with MetricsQL, a superset of PromQL - existing PromQL queries and dashboards work unchanged, with additional functions (histogram_quantile alternatives with better accuracy on VictoriaMetrics’s native histogram buckets, for instance) available as an upgrade path, not a requirement.

Choosing Between Them

  • Thanos if you’re already running vanilla Prometheus per-cluster and want to add global query view and object-storage retention on top with minimal architectural change - it works alongside existing Prometheus rather than replacing its write path.
  • Cortex if you need Prometheus-API-compatible horizontal scale and multi-tenancy and don’t have a strong reason to prefer its newer alternatives - though most new deployments now default to Mimir instead, given the shared lineage and Grafana Labs’ current focus.
  • Mimir for the same use case as Cortex, with generally simpler operations and higher practical cardinality limits - the default recommendation today for a Cortex-shaped need, especially in a Grafana-centric stack (Grafana, Loki, Tempo, Mimir as a matched set).
  • VictoriaMetrics when storage cost and query speed at scale are the primary concern - its efficiency advantage is the most commonly cited reason teams migrate to it, at the cost of not sharing Cortex/Mimir/Thanos’s direct architectural lineage with Prometheus.

All four are drop-in as a remote_write target from unmodified Prometheus, and all four are queryable via the same Prometheus HTTP API from Grafana - migrating between them later is a configuration change, not an application rewrite, which lowers the cost of picking one now and revisiting later if scale or cost characteristics change.

Best Practices

  1. Start with monolithic/single-binary mode for both Mimir and VictoriaMetrics - split into the full microservices/cluster topology only once you’ve measured an actual bottleneck a single process can’t handle; premature clustering is pure operational overhead.
  2. Enable multi-tenancy (X-Scope-OrgID / the insert path tenant ID) from day one even with a single tenant - retrofitting tenant isolation onto data already written without it is far more disruptive than starting with it.
  3. Benchmark with your actual cardinality and query patterns, not published benchmarks - the efficiency gap between these systems varies significantly with label cardinality and query shape, and a synthetic benchmark rarely matches a specific workload’s real profile.
  4. Keep local Prometheus (or vmagent) retention short once remote storage is in place - the local TSDB only needs enough retention to survive a remote-storage outage without losing data, not to serve as the actual long-term store.

Conclusion

Mimir and VictoriaMetrics are both credible, actively developed answers to the same problem Thanos and Cortex first solved - global query view and long-term retention beyond a single Prometheus node’s limits - with Mimir favoring architectural continuity with Cortex and Grafana-stack integration, and VictoriaMetrics favoring raw storage and query efficiency from a different underlying design.

Additional Resources