Thanos vs Grafana Mimir vs VictoriaMetrics

The three platforms attach to Prometheus in different places, and that choice decides what you change on your existing servers. Thanos keeps Prometheus as the scraper and adds components beside it. The Thanos sidecar reads the TSDB blocks each Prometheus server produces and uploads them to object storage, and the Thanos docs describe that upload as happening every 2 hours. The sidecar depends on one setting in the Prometheus configuration: the min and max block duration must be set to equal values to disable local compaction, because the sidecar docs warn that otherwise uploaded data can be corrupted. Thanos Receive takes the other route, accepting Prometheus remote write, so the servers push instead of being read. Thanos is built to run as a distributed system, and its getting started guide does not recommend production use on a single node. Plan at least a small set of components, not one process. The Thanos compactor also has a hard constraint: it must run as a singleton against each object storage bucket. Confirm that your scheduler will never start a second instance against the same bucket during a rollout or failover.

Grafana Mimir replaces the Prometheus storage path with its own cluster. Prometheus writes through the remote write API to the distributor, and PromQL queries go to the query frontend, so every server that feeds Mimir needs a remote write configuration and every query consumer needs the Mimir query path. Mimir requires a tenant ID header on every HTTP request and leaves authentication to an external reverse proxy, so you must build that proxy layer yourself. Internally, the classic architecture uses stateful ingesters with local write-ahead logs. From Mimir 3.0, the preferred ingest storage architecture uses Kafka as a central pipeline that decouples reads from writes. Choosing the ingest path is a decision you make before deployment, because it determines whether you must operate a Kafka cluster. Mimir components compile into a single binary, and the -target parameter selects which components run, with monolithic mode running all of them in one process for smaller installs.

VictoriaMetrics has the simplest attachment model of the three. Prometheus, or a Prometheus-compatible agent, sends data with remote write to a single small binary configured through command-line flags, with no external dependencies. The README also lists ingestion from many other protocols, so the same endpoint can receive other sources. The main decision is whether one single-node instance is enough or whether you need the cluster version, which is also Apache License 2.0 licensed. Confirm the storage target before you commit, because the README says VictoriaMetrics supports NFS-based storage such as Amazon EFS and Google Filestore. Remember that VictoriaMetrics keeps data on the volumes it manages, so your backup and retention runbook must cover those volumes directly, not an object bucket. Also check your remote write buffering and retry settings on each Prometheus server, since those determine how much data is at risk if the endpoint is unavailable.

Implementing Thanos is mostly configuration across several components that you run beside existing Prometheus servers. The Thanos sidecar needs each Prometheus instance to upload blocks, and the Thanos docs require min-block-duration and max-block-duration to be set to equal values so local compaction is disabled, otherwise uploaded data can be corrupted. You then create one object storage bucket, and the Thanos compactor must run as a singleton against that bucket. Plan the retention and downsampling rules at the same time: the compactor downsamples raw data older than 40 hours to 5-minute resolution and 5-minute data older than 10 days to 1-hour resolution. Store gateways, Query and Query Frontend also need sizing and placement, and the getting started guide says Thanos is not recommended for production on a single node, so budget for several hosts.

Implementing Mimir is a Kubernetes project. Grafana publishes the mimir-distributed Helm chart for installing, configuring and upgrading the cluster, so the team needs working Kubernetes skills, persistent storage classes and an object storage bucket with credentials that the pods can reach. Mimir requires a tenant ID header on every HTTP request and leaves authentication and authorization to an external reverse proxy, so you must design and operate that proxy, including how tenant identity maps to the header. From Mimir 3.0, the preferred ingest path uses Kafka, which adds a broker tier to operate. The migration path from Thanos is the step most often underestimated. Grafana's migration guide covers moving Thanos or Prometheus data into Mimir, but Mimir does not support Thanos downsampling, so downsampled blocks and duplicate HA blocks must be removed. Confirm with Grafana exactly what your data set will lose before you cut over.

Implementing VictoriaMetrics starts with the smallest moving part set. The single-node binary is configured through command-line flags and needs no external dependencies, so a single host with a Prometheus remote_write block is a common first deployment. Moving to the cluster version means deciding the topology of its components and how remote write reaches them, and this is where Kubernetes or configuration management skills matter. Storage is local block storage or NFS-based storage such as Amazon EFS, so confirm storage latency and capacity with your own tests instead of assuming them. Downsampling is an Enterprise feature, so if your retention plan depends on it, confirm the license terms and evaluation options with VictoriaMetrics before you design around it. In every option, your team must supply the Prometheus configuration changes, access to the object storage or block storage, and a migration test that compares query results on a copy of real data before anything goes live.

Check the figures in this comparison against the primary sources before you commit to a design. For Thanos, start with the thanos-io/thanos GitHub releases page, which lists v0.42.0 (July 8, 2026) and v0.42.4 (July 30, 2026), and the component pages for Sidecar, Receive and Compact. For Grafana Mimir, the grafana/mimir GitHub releases page shows the current 3.2 line and the 3.1 line that is still receiving fixes, and the Mimir architecture documentation explains the classic and ingest storage paths. For VictoriaMetrics, the VictoriaMetrics releases page shows the roughly two-week cadence, and the README is the place to read the current edition boundaries. Each project's own changelog and release notes are the authority on what a given version changed.

Some points cannot be settled from public documentation alone. Ask VictoriaMetrics for the current list of Enterprise features and confirm which of them, such as downsampling, multiple retentions and backup automation, your team would need in production. Confirm the LTS release lines, their support windows and the trial license terms for Enterprise and LTS builds. Ask Grafana whether Mimir's release support windows and the Kafka-based ingest path meet your requirements, and confirm the status of the Thanos migration guidance for your Mimir version. For Thanos, confirm the support expectations for the Thanos version you pick, since the project is a CNCF Incubating project and its maintenance policy is set by the maintainers.

Verify the licensing position in writing before procurement. Thanos is Apache-2.0, Mimir is AGPL-3.0-only and VictoriaMetrics single-node and cluster are Apache-2.0, but your legal team should check how AGPL-3.0 obligations apply if you modify Mimir and offer it to users. Ask any vendor that sells support or Enterprise tiers for the written feature matrix and the support terms, and keep those documents with your evaluation record. DeployOpen can help you map these questions to your environment and scope the checks as part of a written plan, but the authoritative answers come from the projects and vendors named here.