Notes / Observability / Reference

What is Mimir

Grafana Labs' horizontally-scalable, multi-tenant long-term storage for Prometheus metrics — the 2022 successor to Cortex, and the actual system serving every PromQL query and remote-write in a Grafana Cloud metrics stack.

Updated July 12, 2026 · §202607121601-5 ·

Mimir is Grafana Labs’ open-source, horizontally-scalable, multi-tenant backend for What is Prometheus metrics — the project Grafana Labs built starting in 2022 as the successor to Cortex (Cortex was a CNCF project; Grafana Labs stepped back from co-maintaining it to focus engineering effort on Mimir). It implements the Prometheus remote-write API on the write side and the PromQL query API on the read side, at a scale a single Prometheus server was never built for.


Microservice architecture: write path and read path

Write path                              Read path
───────────                             ──────────
remote_write                            Grafana / API client
     │                                        │
     ▼                                        ▼
 Distributor  (validate, shard by tenant+series)   Query-frontend  (split, cache, dedupe)
     │                                        │
     ▼                                        ▼
  Ingester  (in-memory, recent blocks)     Querier  (merges ingester + store-gateway data)
     │                                        │
     ▼                                        ▼
 Object storage (S3 / GCS / Azure Blob)  ◀── Store-gateway  (serves historical blocks)


 Compactor  (merges + downsamples blocks over time)

This split — distributor/ingester on write, querier/query-frontend/store-gateway on read, object storage as the durable tier, compactor running continuously in the background — is the same shape What is Loki and What is Tempo use. All three were built by the same team around the same pattern, which is why they scale, upgrade, and operate almost identically once you’ve learned one of them.

Multi-tenancy

Every request carries an X-Scope-OrgID header identifying the tenant; Mimir isolates storage, limits, and query execution per tenant on that basis. This is the literal implementation of “tenant” in the cardinality-budget vocabulary — a workload team’s series count, ingestion rate, and query load are capped independently of every other tenant sharing the cluster.

Tenant limitWhat it protects against
Max active series per tenantOne workload’s What is Cardinality (in observability) explosion consuming shared ingester memory
Max samples/sec ingestedA misconfigured scrape interval or retry storm flooding the write path
Max query concurrency / series scannedA single runaway PromQL query starving other tenants’ queries

These per-tenant caps are explicitly the last line of defense in the cardinality mitigation hierarchy — the goal is never hitting them because the label schema was designed correctly upstream.

Why Prometheus-compatible matters operationally

Because Mimir speaks the same remote-write and PromQL APIs, nothing about how a service is instrumented or how a dashboard is written changes when the backend is Mimir instead of a single Prometheus — the migration is purely at the collector’s remote_write target and at query routing, not at instrumentation or dashboard JSON.

Why it matters here: Mimir is literally the metrics system of record in the ShipSolid Grafana Cloud stack — every Alloy remote_write block and every dashboard PromQL query ultimately resolves against Mimir’s distributor/querier, and every new label proposed anywhere upstream (scrape config, StatsD receiver, exporter) is a Mimir active-series cost before it’s anything else — the What is Cardinality (in observability) budget check happens before the config ships, not after ingesters start paging.

Local graph

Full graph →

Linked from 22 notes

8 — Query Sharding

Splitting a single logical query into N independently-executable sub-queries that run in parallel and merge into one result — how Grafana Mimir and Loki answer high-cardinality queries within tight SLOs without adding more data shards.

What is Cortex (cortexproject)

CNCF Incubating, horizontally-scalable multi-tenant long-term storage for Prometheus — the project Grafana Mimir forked from in 2022, still maintained as the vendor-neutral, community-governed alternative once Grafana Labs redirected engineering effort to Mimir.

2 — Shards vs Workers

Clarifies the distinction between shards (persistent data partitions) and workers (execution units): workers fan out to query shards, each concept serves a different dimension of scale.

What is Loki

Grafana Labs' log aggregation system — 'like Prometheus, but for logs': index only labels, store compressed chunks in object storage, query with LogQL. Shares its distributor/ingester/compactor architecture with Mimir and Tempo.

What is Prometheus

CNCF's second graduated project (2018) — the pull-based metrics monitoring system and query language (PromQL) that defined the exposition format nearly every metrics tool now speaks, and the API that Grafana Mimir scales out horizontally.

Grafana Cloud Deployment

How Alloy exports traces, metrics, and logs to Grafana Cloud, including credential architecture, Azure Key Vault setup, and troubleshooting.

3 — Prometheus in the Observability Ecosystem

Where Prometheus sits in the CNCF landscape — its pull-based cloud-native origins, its companion projects, and where this book does (and doesn't yet) connect it to the wider stack.

1 — Prometheus Components

The functional pieces inside a Prometheus server — scrape manager, TSDB, rule engine, query engine — and the real commands used to install and run one on a VM, under systemd, or in Docker.

2 — Long-Term Storage

Why single-node Prometheus has no built-in long-term-storage or HA story, and how remote_write receivers like Thanos, Cortex, Mimir, and VictoriaMetrics fill that gap at a horizontally-scaled, multi-tenant layer.

Chapter 3 — Monitoring at Scale

Prometheus, Mimir, Cortex, and Thanos as the horizontally-scaled answer to a single Prometheus instance running out of room.

3.7 Data Tiering and Compaction (Mimir/Thanos)

Data tiering and compaction in Mimir/Thanos — the ingester-to-object-store journey, compaction levels, vertical compaction/dedup, compaction storms, and the config knobs that control them.

7. Component Map (What Exists in the Wild)

OSS and managed-SaaS options for every layer of the telemetry ingestion pipeline, mapped against ShipSolid's own production experience.