What’s New in Grafana Mimir 3.0? Faster Queries, Decoupled Read/Write, and Lower Costs

Performance and Resource Efficiency

Grafana Mimir 3.0 introduces three primary improvements: (1) full separation of read and write paths to increase reliability, (2) a streaming query engine that avoids loading entire data blocks into memory, and (3) cost optimisation that reduces CPU and memory consumption by up to 15 % in large‑scale clusters.

Architecture Refactor: Decoupling Read/Write Paths

The legacy architecture used a single ingester component for both ingestion and query handling. Under heavy query load the ingester became a bottleneck, throttling write throughput. Mimir 3.0 inserts an asynchronous buffer based on Apache Kafka between the write path and the query path. Writes are first persisted to Kafka topics; downstream components consume the data and store it in the ingest storage, while query services read directly from the storage without touching the write pipeline. This design allows the two paths to scale independently and eliminates cross‑interference.

Role of Ingest Storage

Ingest storage is now a dedicated component that exclusively handles either reads or writes. Because write traffic no longer competes with query traffic, write latency remains stable even when query volume spikes. The clear separation also simplifies capacity planning: operators can add read‑only replicas for query scaling without affecting the write side.

Memory‑Efficient Query Engine (Mimir Query Engine)

The Mimir Query Engine (MQE) was first introduced in version 2.17 and became the default engine in 3.0. Unlike the traditional PromQL engine, which materialises entire result sets in memory, MQE processes results in a streaming fashion: each operator pulls only the samples required for the next step, discarding them immediately after use. Benchmarks show up to a 92 % reduction in peak memory usage and a noticeable increase in query latency under load. MQE is 100 % compatible with existing PromQL expressions, so no query rewrite is required.

Upgrade Checklist for Mimir 3.0

Because the release changes the cluster topology, a staged migration is recommended. Ensure the following conditions are satisfied before starting the migration:

A running Mimir cluster that uses the legacy monolithic architecture.

Administrative rights to deploy a second, parallel Mimir cluster (e.g., via Helm or Jsonnet).

Ability to configure write clients such as Prometheus or OpenTelemetry Collector to send data to both the old and the new endpoints.

Ability to point read clients (Grafana, Thanos Query, etc.) to the new cluster once it is ready.

Access to modify Helm charts or Jsonnet manifests for both clusters to adjust storage, Kafka, and query‑engine settings.