Prometheus Long-Term Storage in 2026: Thanos vs Mimir vs VictoriaMetrics vs Cortex

Prometheus deliberately does not solve long-term storage. It keeps a local TSDB, it expects you to scrape and alert, and it hands the durability problem to someone else. That is a reasonable design choice and it is why this category exists.

The four names you will be choosing between are Thanos, Grafana Mimir, VictoriaMetrics and Cortex - and the honest first question is whether you need any of them.

Do you actually need this?

Raising local retention and attaching a larger disk is the cheapest correct answer, and it covers more teams than this category’s marketing suggests. You need a storage layer when one of three things is true:

• A global query view across several Prometheus servers, rather than a dashboard per cluster.
• Retention in years, usually because a regulator, a capacity-planning cycle or a year-over-year comparison demands it.
• Multi-tenancy, where separate teams or customers must not see each other’s metrics.

If none of those hold, adding a distributed system buys operational burden and no capability. Our Prometheus vs VictoriaMetrics comparison covers the single-server question in more depth.

The deciding axis: how much has to change

1. Thanos - additive, and the least disruptive

Apache 2.0. CNCF project.

Thanos attaches a sidecar to the Prometheus servers you already run, ships TSDB blocks to object storage, and adds a query layer that fans out across them. Prometheus keeps scraping exactly as before, which is the single biggest argument in its favour: adoption is additive rather than a migration.

That design also means the pieces are individually comprehensible - sidecar, store gateway, compactor, querier - and you can adopt them incrementally rather than standing up a distributed system on day one.

Pick it when you have existing Prometheus servers that work and you want a global view and durable retention without changing how collection happens. It is usually the cheapest to adopt for exactly that reason.

2. Grafana Mimir - built for very large scale

AGPLv3.

Mimir is Grafana’s fork of Cortex, and it is where that lineage’s engineering effort has gone. It takes remote-written samples into a purpose-built distributed system and is designed for scale - Grafana advertises 1 billion active series and beyond, with high availability, multi-tenancy and fast queries over long ranges.

The cost is operational weight. Mimir is a distributed system with multiple components, and running it well is a real skill rather than a Helm install. If you are not at a scale where Thanos strains, Mimir is a heavier answer to a question you do not have.

Pick it when you are genuinely at large scale, need hard multi-tenancy, or are migrating off Cortex - where it is the natural destination. Our Thanos vs Mimir comparison goes deeper on that specific choice.

Note the licence. Mimir is AGPLv3, which is a different proposition from Thanos and VictoriaMetrics for anyone embedding it in a product.

3. VictoriaMetrics - the efficiency argument

Apache 2.0, with enterprise features.

VictoriaMetrics is a separate time-series database rather than a layer over Prometheus, and it competes on resource efficiency. The headline claims are large: handling millions of unique series with up to 7x less RAM than Prometheus, Thanos or Cortex, and 10x less than InfluxDB.

Those are the vendor’s own benchmarks, and most comparison articles repeat them without saying so. The architecture genuinely is leaner and teams do report lower resource use - but the multiplier you get depends on your cardinality shape, which is the thing that actually drives memory behaviour. Benchmark it on your own metrics before building a business case on someone else’s number.

On licensing, VictoriaMetrics is Apache 2.0 and the company has publicly committed to keeping it there rather than moving to source-available - notable in a market where several projects went the other way. But check the boundary: anomaly detection, backup automation, multiple retentions, downsampling and stable LTS releases are enterprise features requiring a commercial contract.

Downsampling is the one that catches people out, because it is exactly what you want for multi-year retention, and discovering it is enterprise-only after you have committed is an unpleasant conversation.

Pick it when resource cost dominates your decision, or you want one system rather than Prometheus plus a storage layer.

4. Cortex - not dead, not where you start

Apache 2.0. CNCF Incubating.

Cortex is on the 1.18.x line and development has effectively stalled - the maintainers migrated to Mimir, which is the fork of this project. Most write-ups either ignore Cortex or declare it dead, and neither is quite right.

The accurate position: it is in maintenance mode. It remains a CNCF Incubating project, still ships releases, and still had a KubeCon talk in April 2026. So:

• For a new deployment, do not pick it. The lineage’s future is Mimir and choosing Cortex now means adopting a system whose maintainers have already moved.
• If you already run it and it works, you do not have an emergency. Plan a migration on your own timeline. Grafana documents a path where Thanos can query Mimir during the transition, so it can be incremental rather than a cutover.

That distinction matters because “deprecated” gets used to mean both stop using this today and do not start with this, and only the second applies here.

How to choose in practice

1. Check you need it. Global view, multi-year retention, or multi-tenancy. If none apply, increase local retention.
2. Decide how much change you will accept. If the answer is “as little as possible”, the decision is Thanos and you can stop reading.
3. Be honest about your scale. Mimir’s capabilities are real and so is its operational weight. Most teams asking about 1 billion active series do not have 1 billion active series.
4. Benchmark the efficiency claim. If VictoriaMetrics’s resource advantage is your reason, test it against your own cardinality rather than the published multiplier.
5. Check the licence against your use. AGPLv3 for Mimir, Apache 2.0 for the rest, and the enterprise boundary on VictoriaMetrics.

The failure mode across all four is the same, and it is not the tool: teams adopt long-term storage, retain everything at full resolution forever, and discover eighteen months later that the expensive part was never the storage tier but the cardinality they never controlled. Deciding what not to keep is the work that makes any of these affordable.

If your observability bill is growing faster than your traffic, that is usually a cardinality and retention problem rather than a storage-engine problem - which is what our performance audit looks at first. Tell us what you are retaining and why.