cloudparts

Grafana Mimir

Long-term, multi-tenant storage for Prometheus metrics: it takes remote write and OTLP, keeps Prometheus TSDB blocks in object storage and answers PromQL across them.

What it is
Metrics,Time-series databases
Used for
Observability,Alerting
Type
Open source
Made by
Grafana Labs
License
AGPLv3
Facts checked
24 October 2026
Website Source code

What it is

A single Prometheus server keeps about two weeks of data on one disk and is not clustered. Mimir is where many Prometheus servers, Grafana Alloy or OpenTelemetry Collectors send their samples instead, through Prometheus remote write (Snappy-compressed protobuf over HTTP) or native OTLP at /otlp. Every request carries a tenant ID in a header, and each tenant’s series go into their own Prometheus TSDB. By default a block covers two hours; finished blocks are uploaded to Amazon S3, Google Cloud Storage, Azure Storage or Swift, where a compactor merges and deduplicates them and store-gateways serve them to queries.

Mimir 3.0, released in October 2025, made ingest storage the preferred architecture: distributors validate writes and shard series across partitions of a Kafka topic, and a write succeeds once Kafka has replicated it. Each ingester consumes one partition, keeps recent data queryable, usually within a second, and uploads blocks. Reads go through a query frontend, which splits and caches queries, to queriers that read from ingesters and store-gateways. 3.0 also made the Mimir Query Engine the default, which streams data and, by Grafana Labs’ measure, uses up to 92% less peak memory than the Prometheus engine. The classic architecture, with replicated ingesters and local write-ahead logs, is still supported.

Why teams pick it

  • Speaks Prometheus: remote write in, PromQL, recording and alerting rules out, so Grafana dashboards and alerts work unchanged
  • Keeps months or years of metrics in object storage, which is far cheaper than local disks on each Prometheus server
  • Built for scale and many teams: Grafana Labs says it scales to 1 billion active series, with per-tenant isolation and limits
  • Accepts OpenTelemetry as well as Influx, Graphite and Datadog formats, so one store can replace several

Watch out for

  • A distributed system with many components (distributor, ingester, querier, query frontend, store-gateway, compactor) plus caches, and now Kafka for the preferred architecture; for one small cluster a single Prometheus is far simpler
  • By default a query right after a write may not see it yet; a client must send X-Read-Consistency: strong and accept extra latency to read its own writes
  • No authentication of its own: an external reverse proxy has to check credentials and set the tenant header
  • Cardinality still costs memory in ingesters, so labels with unbounded values hurt here as they do in Prometheus

Good for

Specs

Compare with alternatives →
Data model
Prometheus time series: labelled samples, in a TSDB per tenant
Query language
PromQL
Client protocol
Prometheus remote write and OTLP; Influx, Graphite and Datadog formats
Consistency
Reads may miss a fresh write unless they send X-Read-Consistency: strong
How it scales
Series sharded across Kafka partitions, one ingester per partition
Replication
Kafka replicates writes (ingest storage); replicated ingesters in the classic architecture
Storage format
Prometheus TSDB blocks (two hours by default) in object storage
Retention
Months or years of blocks in object storage

Alternatives

What all metrics have in common →Compare side by side →
PrometheusOpen sourceThe standard open-source metrics system: it pulls numbers from your services over HTTP, stores them as labelled time series and alerts on PromQL queries.InfluxDBOpen sourceAlso good for high-cardinality time seriesThe best-known time-series database, fed by line protocol and Telegraf; now in its third generation, a Rust rewrite that keeps data as Parquet files on object storage.GreptimeDBOpen sourceAlso good for high-cardinality time seriesA Rust database that stores metrics, logs and traces as tables on object storage, queried with SQL or PromQL.

How it fits with other technologies

prometheus.yml: send every sample to Mimir as tenant team-a · yaml

remote_write:
  - url: http://mimir:8080/api/v1/push
    headers:
      X-Scope-OrgID: team-a      # the tenant; normally set by an auth proxy

# Grafana then queries Mimir as a Prometheus data source at
# http://mimir:8080/prometheus with the same header.

See it in a real stack

Self-hosted observability on the LGTM stack →
Live model
What you’re watchingServices emit logs, metrics and spans (three colours) to a collector, which routes each signal to Loki, Mimir or Tempo; all three write their data to object storage. Engineers’ dashboards and searches go through Grafana, which sends LogQL, PromQL or TraceQL to the matching store, and the answers come back from recent data and from the bucket.
Where it came from2016–2026

Prometheus was designed as one server with local storage, so companies running hundreds of them needed somewhere to keep metrics longer and query them together. In 2016 Tom Wilkie and Julius Volz started Cortex at Weaveworks, a horizontally scalable, multi-tenant Prometheus that became a CNCF sandbox project in 2018. Cortex became the basis for other projects, including Loki, Tempo and Grafana Labs’ commercial Grafana Enterprise Metrics.

By 2022 Grafana Labs was putting more work into its proprietary version than into Cortex, while cloud providers sold Cortex-based services without contributing back, a pattern its announcement called “simply not sustainable”. On March 30, 2022, it released Grafana Mimir, a fork of Cortex under AGPLv3 that brought the enterprise scaling features into open source: a split-and-merge compactor for very large tenants and a sharded query engine. Grafana Labs said most Cortex setups could switch in under 10 minutes and that Mimir queried up to 40 times faster.

Mimir completed what Grafana Labs calls the LGTM stack: Loki, Grafana, Tempo and Mimir. Mimir 3.0, in October 2025, moved to a Kafka-based ingest path and a new streaming query engine; 3.2 followed in August 2026.

Why it’s built this way

Reuse the Prometheus TSDB format
Mimir’s storage format is based on Prometheus TSDB: each tenant gets its own TSDB that cuts two-hour blocks with an index and chunks of about 120 samples, so Prometheus’s storage model and PromQL carry over to months of data in a bucket.
Fork Cortex rather than keep contributing
Grafana Labs wanted the scaling features it had built for its enterprise product and Grafana Cloud in an open-source project it controlled. It used AGPLv3, as for Grafana, Loki and Tempo since 2021, whose conditions ask anyone who modifies the software and offers it over a network to share the source.
Multi-tenancy from the start
Cortex was built to run as a shared service for many customers, so every write and query carries a tenant ID and limits apply per tenant.
Kafka between writes and reads (3.0)
In the classic design the same ingesters handled writes and served queries, so a heavy query could slow ingestion. Writing to Kafka first lets reads and writes scale separately.

Timeline

  1. 2016

    Tom Wilkie and Julius Volz start Cortex at Weaveworks

  2. 2022

    Grafana Mimir released in March as an AGPLv3 fork of Cortex

  3. 2025

    Mimir 3.0 in October: Kafka-based ingest storage and the Mimir Query Engine

  4. 2026

    Mimir 3.1 in June and 3.2 in August

Sources10 · facts checked 24 October 2026

Improve this page on GitHub