Continuous Profiling Grows Up as a First-Class Observability Signal
Continuous profiling has moved alongside metrics, logs, and traces as a fourth pillar in modern observability stacks. While metrics highlight symptoms such as elevated CPU, and traces pinpoint slow services, profiles reveal exactly which function and line of code are consuming resources. This level of granularity is increasingly essential as distributed systems grow more complex and traditional debugging becomes harder to apply in production. Grafana Pyroscope addresses this need as an open-source continuous profiling database, designed to capture performance data continuously rather than relying on ad hoc sampling. The recent OpenTelemetry decision to include profiles as a core telemetry signal, with an alpha Profiles specification and native OTLP support in Pyroscope 2.0, signals that application profiling is no longer a niche practice. Instead, it is becoming a standard capability that complements existing performance monitoring tools and enables more precise, cost-aware optimizations.
A Rearchitected Storage Engine Targets Cost and Data Bloat
Pyroscope 2.0 is a ground-up rearchitecture of the continuous profiling database, aimed squarely at storage efficiency and scalability. Earlier versions were based on the Cortex architecture, which replicated every incoming profile three times on the write path. Because a single profile can reach tens of megabytes, this 3x amplification significantly inflated storage usage. The new design writes each profile once to object storage, which now serves as the single source of truth for distributed deployments. Beyond removing redundant writes, Pyroscope 2.0 co-locates profiles from the same service, enabling aggressive deduplication of symbolic information such as function names, file paths, and stack traces. In Grafana’s own production environment, this approach has cut symbol storage by up to 95%. The result is a continuous profiling database that promises to keep long-term retention viable without the infrastructure bloat that often undermines performance monitoring tools at scale.
Stateless Queries and Leaner Operations for Bursty Workloads
The read path in Pyroscope 2.0 has been redesigned around stateless queriers, a major change from the stateful components used previously. Profiling workloads are naturally bursty: day-to-day traffic is low, but incidents or intensive investigations can trigger sudden spikes in query volume. With stateful query services, teams had to provision capacity for the worst case and pay for idle resources most of the time. Stateless queriers allow any instance to serve any request, so operators can scale query capacity elastically in response to demand. This architecture also aligns with emerging patterns in which LLM-powered agents query profiling data automatically during incident analysis. Operational complexity drops alongside resource usage: disk-based segment writers and the separate store-gateway component have been removed, and upgrades that previously took many hours can now complete in minutes. Fewer moving parts mean fewer failure modes and a smoother path to maintaining continuous profiling in production.
New Capabilities Built on a Cleaner Data Model
By simplifying its core data model and decoupling reads from writes, Pyroscope 2.0 unlocks features that were hard or impossible to implement in earlier versions. One addition is metrics derived from profiles: aggregated views that compare performance across services or deployments without scanning individual profiles. This bridges continuous profiling data with familiar dashboard-driven workflows in performance monitoring tools. Another capability is the ability to inspect a single profile instance, not just aggregates, which helps teams reproduce and understand specific regressions. Heatmap queries further enrich application profiling by visualising the distribution of CPU or memory hotspots over time, making it easier to see how changes in code or traffic patterns affect behavior. These features are not bolt-ons; they fall naturally out of the new architecture, demonstrating how a purpose-built continuous profiling database can offer richer insight while also reducing storage and operational overhead.
Open Source Ecosystem and Practical Adoption at Scale
Pyroscope 2.0 arrives in a competitive and rapidly maturing landscape for continuous profiling. Open-source alternatives like Parca take a different technical route, for example using eBPF-based collection and a custom time-series store to handle similar scale and query challenges. Commercial offerings from observability vendors provide managed profiling for teams that prefer to outsource operations. Grafana Pyroscope’s positioning blends an open-source core with a hosted option in Grafana Cloud Profiles, which has already run the 2.0 architecture in production since 2025 and processed 19.5PB of profiling data. Real-world adopters, such as Monzo and Uber, use continuous profiling to catch regressions early and drive profile-guided optimizations in languages like Go. For performance-conscious teams, the message is clear: it is now practical to keep continuous profiling always on, without accepting runaway infrastructure costs or a heavy operational burden.
