Thanos vs Mimir · Prasanta Kumar Behera

A head-to-head guide for choosing between Thanos and Grafana Mimir: architecture (sidecar and query fan-out vs remote-write), multi-tenancy, downsampling, query performance, operations, licensing and fit for edge and multi-cluster platforms.

Side by side

	Thanos	Mimir
Core model	Pull/fan-out: querier asks sidecars and store gateways (or push via Receive)	Push: remote-write into distributors/ingesters
Existing Prometheus	Kept as-is; sidecar added	Kept for scraping; storage/query move to Mimir (or agents replace servers)
Recent data lives in	Each Prometheus (sidecar) or Receive	Mimir ingesters
Global view	Querier fan-out across sources	Central by design
Multi-tenancy	Via Receive tenants; less built-in limit tooling	Native, with rich per-tenant limits
Downsampling	✅ (5m/1h)	❌ (raw only; relies on query sharding and caching)
HA dedup	At query time and/or vertical compaction	HA tracker on ingest; compactor dedup
Components to run	Fewer to start (sidecar, querier, store, compactor)	More (distributors, ingesters, queriers, frontends, store-gateways, compactor, …)
Licence	Apache-2.0	AGPLv3
Heritage	CNCF incubating project	Grafana Labs, from Cortex

Thanos is like adding a library catalogue that can search the bookshelves already in every classroom, plus an archive for old books. Mimir is building one big central library where every classroom mails its books. The catalogue is easier to add to what exists; the central library is better when hundreds of classes need their own shelves, rules and limits.

Decision guide

Choose Thanos when:

you already run Prometheus per cluster and want a global view and long-term storage with minimal change;
long-range dashboards matter and downsampling is valuable;
a small platform team needs the fewest moving parts to start;
licensing policy prefers Apache-2.0.

Choose Mimir when:

you're building a central metrics service for many teams/tenants with enforced limits;
ingestion scale is very high, and you want every path to scale horizontally;
edge and remote clusters should push (agents) rather than be reachable for queries;
you're standardising on the Grafana stack (Loki, Tempo, Mimir share concepts: tenants, rings, object storage).

Either works for most mid-size platforms. Operational familiarity usually decides more than features.

Questions to answer before choosing

How many active series now and in two years?
How many tenants/teams, and do they need hard limits?
What retention per tier (lesson 06), and do you need downsampled long-range queries?
Are all clusters reachable from the central query layer?
Who operates it, and which stack do they know?
Any licensing constraints?

Try it: a written decision

Using the Thanos and Mimir labs (lessons 04–07), run the same dashboard (7-day and 90-day ranges) against both; note query times.
Count the components/pods each needed in your lab and the configuration lines you wrote.
Simulate a disconnected cluster for 30 minutes in each setup and note what global queries show.
Answer the six questions above for a real or imagined platform.
Write a one-page decision record (context, options, decision, consequences).

Going deeper: hybrid and migration

Hybrids exist: Thanos Receive for push from edge sites, sidecars for data-centre clusters, one querier across both.
Migrating Thanos → Mimir (or back) is possible because both use Prometheus TSDB blocks in object storage, but tenant/label layouts differ, so plan it as a project.
Whichever you choose, keep Prometheus-compatible APIs at the edges (remote write, PromQL), so the backend remains replaceable.

Recap

Thanos: bolt-on, fan-out queries, downsampling, fewer components, Apache-2.0.
Mimir: central push service, native multi-tenancy and limits, horizontal scale, AGPLv3.
Decide from scale, tenants, retention, reachability, team skills and licensing, and write the decision down.

This site is a public version of my personal engineering knowledge hub. It intentionally excludes confidential company information and internal operational details.