Skip to content

GRAFANA 2026-04-22 Tier 2

Read original ↗

Grafana — Introducing Pyroscope 2.0: faster, more cost-effective continuous profiling at scale

Grafana Labs launch post (2026-04-22) for Pyroscope 2.0, a ground-up rearchitecture of their open-source continuous-profiling database. The post ships two architecturally substantive disclosures:

  1. OpenTelemetry's Profiles signal reaching alpha legitimises profiling as a first-class observability signal alongside metrics, logs, and traces — and Pyroscope 2.0 adds native OTLP profiling ingest.
  2. Pyroscope 2.0 abandons the Cortex-derived architecture that Pyroscope 1.x, Mimir, and Loki all started from — eliminating write-path replication, decoupling reads from writes, and making object storage the single source of truth. Adapted to profiling data's specific traits: large payloads, heavy symbolic information, bursty query patterns.

This is a launch post with real architectural substance (~40% of body is the architecture section). Passes scope as Tier-2 Grafana per AGENTS.md borderline-case rule.

Summary

Pyroscope 2.0 is a from-scratch rearchitecture of Grafana Labs' open-source continuous-profiling database, retiring the Cortex-based foundation that the original Pyroscope, plus Mimir and Loki, all started from. The redesign applies the same architectural principles Mimir adopted in its own recent rearchitecture — eliminate write-path replication, decouple reads from writes, make object storage the single source of truth — adapted for continuous-profiling data's specific characteristics (large payloads, heavy symbolic information, bursty query patterns). The result is pitched as dramatically cheaper, faster, and simpler to operate at scale. Alongside the rearchitecture, Pyroscope 2.0 ships native support for the OpenTelemetry Profiles signal, which recently reached alpha, positioning continuous profiling as a first-class observability signal.

Key takeaways

  1. Continuous profiling is the "why is my code slow" signal that metrics/logs/traces cannot answer. The post argues that metrics tell you CPU usage is high, logs tell you a request was slow, and traces tell you which service is the bottleneck — but only a profile tells you which function, on which line, is burning the cycles. Quote: "It's the only signal that tells you why your code is slow or expensive, not just that it is." (Source: sources/2026-04-22-grafana-introducing-pyroscope-2-0)
  2. OpenTelemetry's Profiles signal is now alpha. Announced separately by the OpenTelemetry project, this marks profiling joining metrics/logs/traces as a first-class standard signal. Pyroscope 2.0 adds native OTLP profiling ingest so teams can start sending profiles via the emerging standard today rather than via Pyroscope's native format. This is a meaningful interop milestone: the wire-format lock-in problem for profiling goes away the same way it did for traces and metrics. (Source: sources/2026-04-22-grafana-introducing-pyroscope-2-0)
  3. Pyroscope 2.0 is a Cortex-to-object-storage rearchitecture, not an incremental upgrade. The post explicitly names the lineage: Pyroscope 1.x, Mimir, and Loki "started with" Cortex. All three have since outgrown it. Mimir's recent rearchitecture ("eliminate write-path replication, decouple reads from writes, and make object storage the single source of truth") is the explicit architectural template Pyroscope 2.0 inherits. This is the Cortex → object-store rearchitecture pattern applied to a third signal type. (Source: sources/2026-04-22-grafana-introducing-pyroscope-2-0)
  4. Profiling data has three traits that distinguish it from logs and metrics, and the rearchitecture is adapted specifically for them: large payloads, heavy symbolic information (function names, file paths, line numbers — the symbolic-information payload concept), and bursty query patterns (profiling is typically queried during incidents, not continuously). A straight copy of Mimir's architecture would not fit; the adaptation is the substantive engineering. (Source: sources/2026-04-22-grafana-introducing-pyroscope-2-0)
  5. The "case for always-on profiling" arc has three concrete payoffs. The post frames them as: (a) Infrastructure cost cuts via targeted optimisation — see exactly which functions burn CPU/memory across every service in prod, then optimise instead of overprovisioning; (b) Faster root-cause during incidents via profile diffing — "compare a profile from before and after the regression, diff them, and see exactly which code paths changed. No reproducing in staging, no adding ad-hoc logging, and no guessing"; (c) Code-level latency attribution complementing traces — traces tell you the auth service added 200 ms; a profile tells you 150 ms of that was in a regex compilation that could be cached. The p99 tail-latency framing explicitly called out. (Source: sources/2026-04-22-grafana-introducing-pyroscope-2-0)
  6. Write-path replication is the cost being eliminated. Cortex/1.x-era observability databases replicate each write N-way across ingesters on the write path for durability, which doubles or triples the ingest-side compute and network budget. The redesigned architecture pushes durability down to object storage (which is already N-way replicated internally) and treats the ingest tier as a stateless batch-buffer in front of it. See write-path replication for the concept and decouple-reads-from-writes pattern for the architectural move. (Source: sources/2026-04-22-grafana-introducing-pyroscope-2-0)
  7. Launch-post caveat — quantitative claims are qualitative. The post repeatedly uses "dramatically cheaper," "faster," "simpler to operate," but does not publish benchmarks, cost multipliers, ingest throughput, query latency, or scale numbers. These will likely appear in follow-up deep-dive posts (the Mimir-rearchitecture post is linked as the architectural template — that one has the numbers). Treat Pyroscope 2.0's architectural claims as directionally credible (via the Mimir precedent) but unverified for Pyroscope specifically until follow-up posts land. (Source: sources/2026-04-22-grafana-introducing-pyroscope-2-0)

Systems surfaced

  • Pyroscope 2.0 — the new continuous-profiling database; ground-up rearchitecture, native OTLP profiles ingest, object- storage single-source-of-truth design.
  • Pyroscope (1.x) — the Cortex-derived predecessor; retained as a distinct system entry to document the lineage and contrast.
  • Cortex — the original CNCF horizontally-scalable Prometheus-compatible metrics project; the common architectural ancestor for Pyroscope 1.x, Mimir, and Loki.
  • Grafana Mimir — metrics-database sibling; the template Pyroscope 2.0's rearchitecture follows.
  • Loki — logs-database sibling; also Cortex-derived, also moving toward the object-store-first design.
  • OpenTelemetry — the profiling Profiles signal is now alpha; Pyroscope 2.0 adds native OTLP profiling ingest.

Concepts surfaced

Patterns surfaced

Operational numbers

The post does not disclose quantitative benchmarks for Pyroscope 2.0. The only reference numbers are illustrative example latencies cited in the "why profile" motivation:

  • Example regression attribution: trace shows auth service adds 200 ms to a request; profile shows 150 ms of that is in a cacheable regex compilation. Illustrative, not measured.

Implicitly inherited from Mimir's rearchitecture post (linked but not quantified here): multi-fold cost-efficiency gains, simplified operations, and the full ingest/query-path benchmark set.

Caveats

  • Launch post, not architecture deep dive. Quantitative claims are qualitative. Treat architectural direction as credible (via Mimir precedent) but benchmark claims as pending follow-up posts.
  • OTLP Profiles is alpha. Wire format and semantic conventions can still change; early adopters should expect breakage.
  • "Ground-up rearchitecture" implies migration work. The post doesn't detail the 1.x → 2.0 migration story; continuity of historical profile data across the cutover is not discussed.
  • First-party marketing framing. "Dramatically cheaper, faster, simpler to operate" is the vendor's own claim. Independent verification (benchmarks from adopters, not from Grafana Labs) would strengthen the case.

Source

Last updated · 517 distilled / 1,221 read