Skip to content

PATTERN Cited by 1 source

Cortex → object-store observability-DB rearchitecture

Cortex → object-store rearchitecture is the shared architectural transition that Grafana Labs has now applied three times — once to each of its Cortex-descended observability databases — retiring write-path replication in favour of compute-storage separation with object storage as the single source of truth.

The shared story

All three databases started from the same place:

System Signal Cortex-era starting point
Mimir Metrics Forked from Cortex
Loki Logs Started with the Cortex architecture
Pyroscope 1.x Continuous profiles Built on Cortex

And each is making the same set of moves:

  1. Eliminate write-path replication. Durability delegated to object storage.
  2. Decouple reads from writes. Independent tiers.
  3. Object storage as the single source of truth. Compute-storage separation.

Per Grafana Labs' own retrospective in the Pyroscope 2.0 launch post:

"All three projects have since outgrown that foundation. Mimir recently redesigned its architecture to eliminate write-path replication, decouple reads from writes, and make object storage the single source of truth. Pyroscope 2.0 applies similar architectural principles."

(Source: sources/2026-04-22-grafana-introducing-pyroscope-2-0)

Why it's a pattern, not a coincidence

The same Cortex ancestry created the same set of structural limitations. The same vendor solving them produces convergent designs:

  • All three signal types grew large enough that the N× write-path replication multiplier dominated cost.
  • All three have bursty read patterns (bursty query pattern) that want to scale independently of the always-on write path.
  • All three are telemetry stores where object-storage durability (eleven nines on S3) is strictly better than in-memory-quorum durability at a fraction of the cost.

The adaptations differ per signal:

  • Mimir (metrics): uniform float time-series, narrow payloads, predictable read patterns — object storage fits naturally.
  • Loki (logs): label-based indexing over chunked content; object storage was already the chunk store, the rearchitecture is more about index and ingester.
  • Pyroscope 2.0 (profiles): large payloads, heavy symbolic information, bursty queries — requires new storage-format work on top of the same architectural moves.

Per-signal adaptation is the engineering

This pattern describes what changed architecturally. The actual engineering is how to make it work for this signal's data shape. A straight copy of Mimir into Pyroscope would underperform; Pyroscope 2.0's substantive work is the adaptation. (Source: sources/2026-04-22-grafana-introducing-pyroscope-2-0)

Instances

  • Mimir — metrics; rearchitecture shipped, benchmarks published in Mimir's own blog post.
  • Pyroscope 2.0 — continuous profiles; rearchitecture launched 2026-04-22 at GrafanaCON.
  • Loki — logs; incremental convergence; many features launch in Grafana Cloud Logs first.
Last updated · 517 distilled / 1,221 read