Pyroscope 2.0 reworks continuous profiling storage

Grafana Labs released Pyroscope 2.0 on April 21 with a ground-up redesign of the open-source continuous profiling database. The release article says the new architecture writes each profile once to object storage, co-locates data by service, and makes the read path stateless.

The architecture follows profiling’s workload

Profiles are large, rich in repeated symbolic data, and queried in bursts. Pyroscope’s earlier write path replicated profiles three times, while stateful query components had to be provisioned for peaks. Version 2.0 removes that write amplification and lets queriers scale with demand. Grafana reports substantial symbol-storage reduction in its hosted deployment, but that result is specific to its production workload rather than a universal promise.

For self-hosted teams, object storage is now required for distributed deployments because it becomes the source of truth. That shifts the capacity plan: durable object storage, request rates, compaction behavior, and query compute need separate budgets.

Migration should preserve incident evidence

A useful rehearsal copies a bounded period of profiles into a test environment, runs the same flame-graph and comparison queries on both versions, and records query latency and cost. Engineers should also interrupt a rollout and confirm that the system recovers without orphaning or duplicating data.

The failure case is upgrading the binary while leaving storage assumptions untouched. Object-store throttling or an undersized query tier may appear only when several responders investigate the same incident. Load tests should mimic that burst, not just steady ingestion.

Pyroscope 2.0 aligns the storage model with the economics of profiling. It can reduce persistent state and idle query capacity, but teams still need migration evidence from their own symbol mix, retention policy, and incident-query pattern.