Grafana Mimir

Last reviewed Sep 13, 2026 · 945 words

Grafana Mimir is the wrong tool for a homelab under about a million active series, and that covers nearly every homelab. Its purpose is to take Prometheus metrics past the point where one Prometheus server can hold them: hundreds of millions of series, years of retention, several teams isolated from each other, queries fanned out across dozens of machines. Below that point it is a 1 GB-plus Go process with 10-odd internal components that gives you nothing a --storage.tsdb.retention.time=2y flag would not. The rest of this guide is for the people who do need it, and for the people who need to be talked out of it.

What plain Prometheus cannot do, and Mimir can

A single Prometheus instance stores data on local disk, has no high availability beyond running two identical copies, and answers queries from one process. Those limits are fine to roughly a few million series and a couple of years of retention if you have the disk. Mimir removes each one: ingesters replicate incoming samples (3 copies by default) so an ingester can die without losing the last 2 hours, completed TSDB blocks go to object storage (S3, GCS, Azure Blob, Swift, or a local filesystem for testing) so retention is bounded by your bucket rather than a disk, the query engine splits and shards long-range queries across queriers, and every request carries a tenant ID so one Mimir can serve several isolated teams. It also swallows OpenTelemetry metrics natively, which matters if you are standardising on OTLP.

Prometheus stays in the picture as the scraper. It ships samples via remote_write to Mimir's /api/v1/push endpoint, and Grafana points at Mimir's Prometheus-compatible query API instead of at Prometheus directly. Nothing in your dashboards changes.

Monolithic mode is the only mode a small team should run

Mimir ships as one binary that can run as all components at once (-target=all) or as any single component. Start with the monolith. A working single-node setup is a container and a config file:

multitenancy_enabled: false
blocks_storage:
  backend: filesystem
  filesystem:
    dir: /data/blocks
  bucket_store:
    sync_dir: /data/tsdb-sync
ingester:
  ring:
    replication_factor: 1
server:
  http_listen_port: 8080

Run grafana/mimir with -config.file=/etc/mimir/config.yaml, mount /data, and send Prometheus at http://mimir:8080/api/v1/push. Turning off multitenancy means you do not have to add an X-Scope-OrgID header to every client; leave it on if you actually have tenants. The Helm chart (mimir-distributed) is how you graduate to microservices mode, and that is a Kubernetes project with a real operations budget, not a weekend.

The resource cost is real, not a rounding error

The catalogue's 1 GB minimum is for a monolith idling on a trickle of samples. Ingesters keep the last 2 hours of every series in memory before flushing a block, so memory scales with active series: plan on roughly 1 to 2 KB per active series in the ingester alone at steady state, plus the compactor's working set when it merges blocks, plus store-gateway index headers. A modest 500,000-series install lands comfortably above 4 GB. That is why the catalogue marks it Hard: not because the config is arcane but because you have to understand the internal ring, the block lifecycle, and the compactor to size and debug it.

The cheaper answers for long-term metrics

For one homelab or one small company, three alternatives cost less effort. First, Prometheus with long retention and a bigger disk; retention is a flag, and 2 years of 100,000 series is a few tens of GB. Second, VictoriaMetrics, a single binary that accepts remote_write, compresses better than Prometheus, and runs a multi-year store in a fraction of Mimir's memory; it is the tool I point people at most often. Third, Thanos, which bolts object-storage retention onto existing Prometheus servers via a sidecar rather than replacing the storage path, and is the better fit if you already run several Prometheus instances and want a global view without re-plumbing ingestion.

Mimir wins over all three only when you have genuine multi-tenancy needs, series counts in the hundreds of millions, or an organisation already running the Grafana stack (Loki for logs, Tempo for traces) and wanting one operational model across the three.

Licensing and lineage, briefly

Mimir is a 2022 fork of Cortex by the Grafana team, released under AGPL-3.0 where Cortex was Apache-2.0. The catalogue's claim that it is easier to operate than Cortex matches my experience: the monolithic mode, the consolidated config, and the bundled compactor defaults removed a lot of the sharp edges. AGPL does not affect you if you run it internally; it matters if you were planning to offer it as a hosted service.

What I'd do

For a homelab or a team under about 20 engineers, I would not install Mimir. I would run Prometheus with a 1 to 2 year retention setting, and move to VictoriaMetrics the day the Prometheus process crossed 8 GB of memory or I wanted metrics from 3 sites in one place. I would reach for Mimir when a second team needed its own isolated metrics space, when series counts made a single VictoriaMetrics node uncomfortable, or when I already had Loki and Tempo in production and wanted the monitoring stack to share one storage and scaling story. In that case: monolithic mode on one beefy VM first, object storage from day one, microservices only when a single node demonstrably runs out of room.