# Grafana Mimir: Long-Term Prometheus Storage Without a Single Point of Failure > Grafana Mimir is a multi-tenant, horizontally scalable time series store for Prometheus. It is serious infrastructure with a monolith mode for small setups and a distributed mode for very large ones, but it is not a drop-in replacement for a single Prometheus server. **grafana/mimir** — Grafana Mimir provides horizontally scalable, highly available, multi-tenant, long-term storage for Prometheus. - Repository: https://github.com/grafana/mimir - Website: https://grafana.com/oss/mimir/ - Stars: 5,238 · Forks: 841 - Language: Go - License: AGPL-3.0 - Published: 2026-08-04 · Updated: 2026-08-18 · Language: en - Canonical page: https://hysenlabs.com/projects/grafana-mimir ## What Grafana Mimir is for, and who should care A single Prometheus server stores its data on a local disk. That works until retention grows past what the disk holds, or until one machine cannot keep up with the number of active time series, or until the server is the only copy of your metrics and a disk failure takes the history with it. Grafana Mimir exists to remove those three constraints at once. The README describes it as "a scalable long-term storage for Prometheus", and the phrase that matters is long-term: Mimir writes blocks to object storage rather than to a local volume, so retention is bounded by your object storage bill rather than by a disk. The audience is operators, not application developers. Mimir is a server you deploy, configure, and monitor. It speaks the Prometheus remote write and query protocols, so existing Prometheus servers keep scraping and simply ship samples onward, and existing Grafana dashboards keep querying the same PromQL. The README also lists a migration path from Thanos or Prometheus, and a separate one from Cortex, which tells you the intended audience is teams that already run one of those and have outgrown it. One detail in the README is worth reading carefully rather than skimming. The scalability claim is stated as internal testing handling "up to 1 billion active time series". That is a vendor figure from internal tests, not an independent measurement, and it says nothing about the hardware or the query latency at that size. Treat it as an upper bound the project believes it can reach, not as a sizing guide. ## How Mimir splits ingestion, storage and query Mimir is built from components that can run in one process or be spread across machines. The README names two deployment shapes: monolithic mode, where a single binary runs everything with no additional dependencies, and the horizontally scalable architecture, where components are separated and replicated across machines. The same binary serves both; only the configuration and the number of replicas change. On the ingestion path, Prometheus remote-writes samples to Mimir. Mimir replicates incoming metrics, which the README gives as the reason no data is lost on machine failure. Samples are then written into blocks that land in object storage. The go.mod file shows the object store clients the project compiles against, including the Azure Blob SDK (azblob) and the MinIO client, which is consistent with the README's list of S3, Google Cloud Storage, Azure Blob Storage, OpenStack Swift, and any S3-compatible store. On the query path, Mimir aggregates series from multiple Prometheus instances, which is what the README means by a global view of metrics. The README states the query engine extensively parallelizes execution. That is the architectural answer to high-cardinality queries: work is split and run concurrently rather than on one machine. Multi-tenancy is not bolted on. The README describes a natively multi-tenant architecture where independent teams share one cluster, with limits and quality-of-service controls to share capacity fairly. In practice this is the feature that most changes how you operate the system, because every request carries a tenant identity and every limit is enforced per tenant. ## Installing Grafana Mimir and running a first query The README does not contain installation commands. It points to a Get started guide, a Deploy Grafana Mimir page, and an architecture overview, and it states that monolithic mode gets Mimir running with one binary and no additional dependencies. The repository layout shows where a build would start: the Makefile defines an exes target for building binaries and image targets for containers, and the cmd/ directory holds the entry points. The README still directs new users to the documentation rather than to a build command, so treat the Makefile as the maintainer path, not the getting-started path. The Makefile documents its own targets. Running the help target prints the user-facing ones, which is the only way to see the list without reading the file: ```bash make help ``` The output begins with a usage line and a Targets heading, then one line per documented target with its description. Targets that are not documented in that style do not appear, so the list is shorter than the .PHONY declaration at the top of the file. For a first evaluation, the README's own framing is the guide: monolithic mode, one binary, no additional dependencies. The configuration surface is a YAML file, and the project's configuration documentation describes the keys. The README does not reproduce any of them, so check the version you deploy rather than copying a snippet from a blog post. The step the README does describe in prose is the Prometheus side. Prometheus keeps scraping as before and remote-writes samples to Mimir, which is standard Prometheus configuration rather than a Mimir-specific format. The README's migration guide from Thanos or Prometheus covers that cutover, including the tenant header the write path expects. Finally, Mimir is queried with PromQL through Grafana. The README does not document adding the data source; that lives in Grafana's documentation. What you should see is the same series you scraped, now served from Mimir rather than from Prometheus, and surviving a restart of the Prometheus server that produced them. ## Where Mimir is the wrong tool Mimir is a distributed system, and distributed systems fail in distributed ways. The README's high availability claim rests on replication, which means the failure modes you debug are replication lag, partial writes, and components disagreeing about state, not a single process crashing. If your team has never operated an object-storage-backed metrics pipeline, the operational cost is real and the README does not pretend otherwise: it lists an architecture overview, a configuration guide, and a run-in-production guide as required reading before production. The object store is a hard dependency in any serious deployment. Mimir's durability and cost story both come from object storage, so a deployment without a supported store is not a deployment. That rules out environments where egress or storage costs are unpredictable, and it rules out air-gapped setups unless you run an S3-compatible store internally. Monolithic mode is genuinely useful, but it is a starting point, not a destination. It gives you one binary and no extra dependencies, which is exactly what you want for a first evaluation. It does not give you the horizontal scalability the project is known for, and the README frames the two modes as different deployment shapes rather than interchangeable ones. Finally, if you need logs or traces alongside metrics, Mimir does not cover that. It is a metrics store, and the README never claims otherwise. ## Mimir compared with Thanos and with plain Prometheus The README links a migration guide from Thanos or Prometheus, which is an implicit admission that these overlap. The difference is in where the query work happens. Thanos keeps a Prometheus server in the loop: a Thanos sidecar attaches to each Prometheus instance, uploads blocks to object storage, and a querier fans out across those stores. Mimir removes Prometheus from the storage and query path entirely. Prometheus becomes a scraper that remote-writes, and Mimir owns ingestion, storage, and query. That has two consequences. First, Mimir's multi-tenancy is native, with per-tenant limits and quality-of-service controls; Thanos multi-tenancy is typically arranged at the query layer rather than in the storage engine. Second, Mimir's scaling story is about adding replicas of its own components, not about adding Prometheus servers. If you already run Thanos and it works, the migration guide exists precisely because the move is not free. Against plain Prometheus the comparison is simpler and less flattering to Mimir. A single Prometheus server is one binary, one config file, and local disk. It has no object store dependency and no replication to reason about. Mimir wins on retention, on the number of active series it can hold, and on querying across many Prometheus instances at once. It loses on everything else: setup time, the number of moving parts, and the number of things that can page you at 3am. The right moment to move is when retention or series count is the actual constraint, not before. ## Licence, upgrade cadence and the cost of staying current Mimir is distributed under AGPL-3.0-only. The repository also carries a LICENSING.md file alongside LICENSE, which is a signal that some parts of the tree may be under different terms; if you plan to redistribute Mimir, embed it in a product, or offer it as a service, read both files and get your own legal advice rather than relying on the one-line summary in the README. AGPL-3.0 is a copyleft licence with a network-use clause, and that clause is the part most likely to matter to a commercial deployment. Upgrade cost is visible in the release history: the project ships patch releases on older minor lines (3.1.5 and 3.0.9) alongside a new minor (3.2.0), which is the pattern of a project that maintains several branches at once. The README claims restarts, upgrades, and downgrades happen with zero downtime, which is a property of the replicated architecture rather than a promise about any individual configuration. The CHANGELOG.md at the repository root is where you check what changed; the README does not describe a support window or an end-of-life policy for older minors, and that silence is worth noting if you pin versions for a long time. There is no separate enterprise edition mentioned in the README. The licence is the whole story as far as this repository goes. ## Conclusion Adopt Mimir if you already run Prometheus at a scale where a single server, or a pair of them, no longer holds your retention or your query latency, and you have object storage plus a team that can operate a distributed system. Do not adopt it if you want a single binary for a small homelab: Prometheus itself, or a managed service, costs you less attention. Before committing, verify three things against your own environment: that your object store is on the supported list (S3, GCS, Azure Blob Storage, OpenStack Swift, or an S3-compatible endpoint), that your tenants map cleanly onto Mimir's tenant model, and that you have read the architecture overview and the run-in-production guide, because the README points at both before any production deployment. ## FAQ ### How do I install Grafana Mimir? The README does not give install commands. It points to the Get started guide and the Deploy Grafana Mimir documentation, and states that monolithic mode runs Mimir with a single binary and no additional dependencies. ### How do I install Grafana Mimir? The README does not give install commands. It points to the Get started guide and the Deploy Grafana Mimir documentation, and states that monolithic mode runs Mimir with a single binary and no additional dependencies. ### How do I set up Mimir? Setup starts from the project's Get started guide and its Deploy Grafana Mimir page. Before production the README requires reading the architecture overview, the configuration guide, and the run-in-production guide. ### How do I add a Mimir data source in Grafana? The README does not cover this step; it only describes Mimir as a Prometheus-compatible store that Grafana can query. The Mimir data source configuration lives in Grafana's own documentation. ### What is Grafana Mimir? It is an open source project providing scalable long-term storage for Prometheus. It is multi-tenant, uses object storage for long-term data, and can run as a single binary in monolithic mode or spread across machines. ## Sources - [Official documentation](https://grafana.com/oss/mimir/) - [Official README](https://github.com/grafana/mimir#readme) - [Project repository](https://github.com/grafana/mimir) - [Release notes](https://github.com/grafana/mimir/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/grafana-mimir