Grafana Labs has released Pyroscope 2.0, a ground-up rearchitecture of the open source continuous profiling database. The release, announced on 21 April 2026, addresses storage costs, query performance and operational complexity that had accumulated in the original design.
Continuous profiling sits alongside metrics, logs and traces as the four pillars of an observability stack. Whilst metrics report issues such as high CPU usage, and traces show which service is the bottleneck, a profile goes further, identifying which function, on which line, is consuming the cycles. Christian Simon, a staff engineer at Grafana Labs, writes in the announcement that this distinction matters as systems grow more complex, because it is the level of detail needed to make targeted optimisations rather than simply adding hardware.
"Continuous profiling captures these moments as they happen, so you don't have to rely on luck with a debugger."
Christian Simon, Grafana Labs
The original Pyroscope was built on Cortex, the same foundation used by Mimir and Loki in their early versions, but all three projects have since moved away from it. Simon notes that 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 the same architectural principles, adapted for the characteristics of profiling data: large payloads, significant symbolic information, and bursty query patterns.
The most significant cost reduction comes from removing write-path replication. In v1, every profile was written three times. A single profile can be tens of megabytes, so that 3x amplification had a meaningful effect on storage bills. Pyroscope 2.0 writes each profile once to object storage. The second saving comes from data co-location: profiles from the same service are stored together, allowing symbolic information such as function names, source locations and stack traces to be deduplicated. In Grafana's own production environment, Simon reports that this reduced the symbol storage footprint by up to 95%.
The read path has also been redesigned. In v1, query processing happened inside stateful components that could not scale elastically, meaning capacity had to be reserved for peak load even when it sat idle. Pyroscope 2.0 makes the entire read path stateless: any querier can process any query, and querier count can adjust to demand. Simon notes that profiling has a bursty access pattern, with no meaningful baseline traffic, but heavy concurrent use during incidents. He also observes that LLM-powered agents are increasingly querying profiling data as part of automated investigations, adding a new class of traffic that benefits from elastic scaling.
"With stateless queriers, the system can handle these spikes gracefully without paying for idle capacity the rest of the time."
Christian Simon, Grafana Labs
Operationally, fewer stateful components means fewer failure modes and faster rollouts. Simon writes that deployments that took 8-12 hours in v1 now complete in minutes. The segment writer is diskless and the store-gateway component has been removed entirely.
The new architecture also enables capabilities that were not feasible in v1. These include metrics derived from profiles, which aggregate profiling data into fleet-wide comparisons across services or deployments without querying individual profiles; the ability to inspect a single profile instance rather than only aggregates; and heatmap queries for visualising profile distributions over time. Simon describes these as a consequence of a cleaner data model and stateless read path, rather than a separate engineering effort.
The release comes as profiling is gaining recognition as a standard observability signal. OpenTelemetry announced in August 2024 that it had incorporated continuous profiling as a core telemetry signal, with Elastic donating its continuous profiling agent to the project. OpenTelemetry recently declared its Profiles signal as alpha. Pyroscope 2.0 includes native support for the OpenTelemetry Protocol (OTLP) for profiling, allowing teams to ingest profiles through the standard OpenTelemetry pipeline.
The broader observability community has noted the connection between profiling and cost reduction for some time. An InfoQ article from February 2024 on observability predictions for the year identified FinOps as one of the key forces shaping the field, alongside OpenTelemetry growth and AI integration. Those trends are all present in the Pyroscope 2.0 release: the architectural changes reduce the cost of running profiling at scale, the OTLP support aligns with OpenTelemetry adoption, and Simon explicitly notes that AI agents are now querying profiling data in production.
Pyroscope is not the only open source continuous profiling project. Polar Signals builds Parca, an open source system for collecting continuous profiling data, which uses eBPF for low-overhead collection. Frederic Branczyk, co-founder of Polar Signals, has discussed on InfoQ how eBPF and a custom time-series database called FrostDB address the same storage and query challenges that Pyroscope 2.0 tackles through its architectural redesign.
In terms of commercial alternatives, Datadog, New Relic, Dynatrace and Sentry all serve as alternatives for teams that prefer a managed solution. CubeAPM also offers continuous profiling as part of a full-stack observability platform aimed at organisations that want simpler setup with less operational overhead. Pyroscope's approach of open source code combined with a hosted option in Grafana Cloud Profiles puts it in a different position from these vendors, particularly for teams already running other Grafana stack components.
Real-world use cases for Pyroscope are well-documented. At QCon London 2026, engineers from Monzo described using Pyroscope for continuous profiling to detect performance regressions as they are deployed, alongside a Slack channel called "Graph Trending Downwards" where improved performance is noted. InfoQ covered this presentation in March 2026. Uber has also published details of using profile-guided optimisation in Go, a workflow documented in an InfoQ article from March 2025, with Grafana Labs citing its use of Pyroscope in the same process.
Grafana Cloud Profiles, the hosted version powered by Pyroscope, has been running the 2.0 architecture in production since April 2025. Grafana rolled it out to every region by September 2025 and has since processed 19.5PB of profiling data. For existing Grafana Cloud Profiles users, the migration has already taken place. For teams running Pyroscope themselves, the key change in upgrading from v1 is that object storage is required for distributed deployments, as it is now the single source of truth for all profile data. Migration instructions and release notes are available in the project documentation.