Grafana Mimir: Long-Term Prometheus Storage with a Monolithic Mode and AGPL-3.0 License

The Problem: Prometheus Storage That Does Not Scale Forever

Prometheus is excellent at scraping and alerting, but its local storage is not built for long-term retention across many instances. When you run multiple Prometheus servers, you lose a global view of your metrics, and querying across them becomes a manual exercise. Grafana Mimir solves this by acting as a central, long-term storage backend. It ingests metrics from many Prometheus instances, stores them durably in object storage, and lets you query all of them with a single engine. The intended audience is an organization that runs Prometheus at scale and needs to retain metrics for months or years, not a single-team setup with modest cardinality. The README positions Mimir as easy to install, but the real value is in its horizontal architecture and multi-tenancy, which are for platforms teams, not casual users.

How It Works: Object Storage, Replication, and Parallel Queries

The core mechanism is separation of compute from storage. Mimir uses object storage for long-term data, which means the storage layer is cheap and durable, and the query engine can run on separate machines. The README states that Mimir replicates incoming metrics, so data survives machine failure. The architecture is horizontally scalable, allowing you to add machines to increase capacity. Query execution is parallelized across the cluster, which the README claims makes even high-cardinality queries fast. Multi-tenancy is built in, with limits and quality-of-service controls to share capacity fairly. The data flow is: Prometheus instances send metrics to Mimir, Mimir replicates and writes them to object storage, and queries are executed against that storage in a distributed fashion. This is a pull-based model for Prometheus, but Mimir itself is a push target, so you configure Prometheus's remote write to point at Mimir.

Getting It Running: Monolithic Mode and Deployment Options

The README emphasizes that you can get Mimir running with just one binary and no additional dependencies. This is the monolithic mode, where all components run in a single process. The command to start it is not given in the README, but the documentation link for deployment is provided. For production, you would likely run Mimir in a microservices mode, with separate components for ingesting, storing, and querying. The README points to a deployment guide, which would include configuration files and Helm charts, though those details are not in the supplied material. To migrate from Thanos or Prometheus, there are dedicated guides, which suggests the migration path is well-trodden. The key point is that the barrier to starting is low, but the production setup requires reading the architecture and configuration docs before you begin.

A Genuine Limitation: Object Storage Dependency and AGPL-3.0

The most obvious limitation is that Mimir requires object storage. The README lists AWS S3, GCS, Azure Blob, OpenStack Swift, and S3-compatible stores, but that still means you must operate or pay for a separate storage service. If you are on-premises without an S3-compatible endpoint, you have to set one up, which adds complexity. The second limitation is the license. Mimir is AGPL-3.0-only, which is a strong copyleft license. If you modify Mimir and offer it as a network service, you must release your modifications under the same license. For many internal deployments, this is fine, but if you are building a commercial product that embeds or extends Mimir, you need to review the implications carefully. The README does not mention any alternative licensing, so you should assume AGPL-3.0 applies to any derivative work.

Alternative: Thanos as a Different Approach

The README explicitly mentions migrating from Thanos or Prometheus to Mimir, so Thanos is a direct alternative. The difference in approach is that Thanos typically works as a sidecar to Prometheus, uploading blocks to object storage, whereas Mimir is a centralized service that receives remote writes. Thanos uses a pull-based model for querying, with a query frontend that talks to Prometheus instances or Thanos sidecars. Mimir, by contrast, is a push-based system where Prometheus sends data to Mimir's ingestion endpoint. This means Mimir can provide a global view without needing to access each Prometheus instance, while Thanos requires each Prometheus to be configured with a sidecar. If you already have a fleet of Prometheus instances and want to avoid changing their configuration, Thanos might be less disruptive. If you are starting fresh or want a multi-tenant system, Mimir's architecture is more integrated.

Maintenance and Upgrade Cost

The README claims that Mimir can be restarted, upgraded, or downgraded with zero downtime, which is a strong operational promise. That implies the project has put effort into making upgrades safe, but it also means you need to follow the documented procedures. The maintenance cost is tied to the object storage backend, which you must monitor for latency and costs. The project ships dashboards, alerts, and runbooks, which reduces the burden of building your own monitoring. However, you still need to keep up with releases. The recent release history shows a 3.2.0, 3.1.5, and 3.0.9, with 3.1.5 and 3.0.9 having the same timestamp, which suggests patch releases are frequent. You should plan to read the release notes for each upgrade, as the documentation for the upcoming release is available at the tip of the main branch. The license does not impose a cost, but AGPL-3.0 may require you to share modifications if you distribute a service, which is a legal cost to review.

Editorial conclusion

Adopt Grafana Mimir if you need a multi-tenant, horizontally scalable Prometheus storage backend and can accept the AGPL-3.0 license and the operational overhead of object storage. Do not adopt it if you require a permissive license or want to avoid running a separate storage service. Before adopting, verify your object storage compatibility, review the production runbook for zero-downtime upgrades, and test the monolithic mode against your ingestion rate. The project's claim of handling up to 1 billion active time series is based on internal testing, so validate it against your own workload.

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes