Skip to content

SYSTEM Cited by 1 source

Pyroscope 2.0

Pyroscope 2.0 (grafana.com/blog/pyroscope-2-0-release/) is Grafana Labs' open-source continuous-profiling database, rearchitected ground-up from the original Pyroscope 1.x. Launched at GrafanaCON 2026 (2026-04-22).

What changed vs. 1.x

Pyroscope 1.x was built on Cortex — the same foundation that Mimir and Loki also started from. Pyroscope 2.0 is a from- scratch rearchitecture that applies the architectural principles Mimir adopted in its own recent redesign:

These are the same moves Mimir and Loki made. Pyroscope 2.0 is the third application of the pattern, adapted for profiling data's distinctive traits. See patterns/observability-db-rearchitecture-cortex-to-object-store for the sibling-pattern framing. (Source: sources/2026-04-22-grafana-introducing-pyroscope-2-0)

Why profiling needs its own adaptation

Profiling data differs from metrics and logs in three ways that the rearchitecture accounts for:

  1. Large payloads. A profile is a call-tree / flame-graph structure, not a single sample — individual payloads are substantially larger than a metrics datapoint or a log line.
  2. Heavy symbolic information. Function names, file paths, line numbers, executable build IDs — the symbolic side-table is proportionally larger than the raw sample count and dominates storage for many workloads.
  3. Bursty query patterns. Profiles are queried heavily during incidents ("what got slower between 14:02 and 14:05?") and barely at all between them. Steady-state read-path sizing that makes sense for metrics is wasteful for profiles.

A direct port of Mimir's architecture would underperform on these axes; the 2.0 engineering is adapting the same principles for this data shape. (Source: sources/2026-04-22-grafana-introducing-pyroscope-2-0)

OpenTelemetry Profiles native ingest

Pyroscope 2.0 ships native support for the OpenTelemetry Profiles signal, which recently reached alpha. Teams can send profiles via OTLP today rather than Pyroscope's native protocol, giving profiling the same wire-format portability that OpenTelemetry already provided for metrics, logs, and traces. This is the interop milestone that ends vendor-specific lock-in on the profiling side. (Source: sources/2026-04-22-grafana-introducing-pyroscope-2-0)

The "always-on profiling" thesis

Pyroscope 2.0's motivation rests on default continuous profiling — run profilers on every host, all the time, so the data is already there when an incident starts. Three payoffs the launch post highlights:

  • Targeted cost reduction over overprovisioning. See which functions burn CPU/memory across the fleet, then optimise.
  • Faster incident root cause via profile diffing. Compare before/after profiles, see which code paths changed, no staging repro.
  • Code-level latency attribution. Traces localise blame to a service; profiles localise to a function / line. Especially useful for p99 tail-latency where the spike is hard to reproduce.

Prior art on the same thesis: Meta's Strobelight — fleet-wide profiling as a "flight recorder." Pyroscope 2.0 aims to make the same posture accessible outside hyperscaler-scale orgs. (Source: sources/2026-04-22-grafana-introducing-pyroscope-2-0)

Relationship to Grafana Cloud

Pyroscope 2.0 ships open source. Grafana Labs also operates a managed offering (Grafana Cloud Profiles) in the same pattern as Grafana Cloud Logs for Loki — features typically launch under managed operational control before OSS general availability.

Seen in

Caveats

  • Launch post; no benchmarks published for 2.0 specifically. The post's "dramatically cheaper / faster / simpler" claims are qualitative. Credible by Mimir precedent but unverified for Pyroscope.
  • OTLP Profiles is alpha. Wire format and semantics can still change.
  • Migration story from 1.x → 2.0 is not detailed in the launch post; expect follow-up documentation.
Last updated · 517 distilled / 1,221 read