From Niche Signal to Core Pillar of Observability
Continuous profiling has moved from experimental add-on to a fourth observability pillar alongside metrics, logs and traces. Where metrics highlight symptoms such as high CPU usage and traces reveal which service is slow, profiles expose the exact function and even source line that is burning cycles. This level of detail matters for teams operating large database-backed systems, where performance optimization decisions can mean the difference between tuning a query and overprovisioning hardware. Grafana’s Pyroscope project was created as a continuous profiling database to store and query this high-cardinality data in real time. However, earlier architectures carried storage and operational overhead that limited adoption in complex production environments. With Pyroscope 2.0, Grafana Labs aims to make continuous profiling practical at scale, particularly for organizations that want always-on visibility into query engines, ORMs and application hotspots touching critical databases.
A New Architecture Focused on Storage Cost Reduction
Pyroscope 2.0 is a ground-up rearchitecture of the continuous profiling database, inspired by recent changes in other Grafana projects such as Mimir. The most important shift for cost-conscious teams is the removal of write-path replication. In version 1, every profile was written three times, an expensive proposition given that individual profiles can be tens of megabytes. The new design writes each profile once to object storage, which now acts as the single source of truth. Pyroscope 2.0 also colocates profiles from the same service, allowing it to aggressively deduplicate symbolic data like function names, file paths and stack traces. Grafana reports symbol storage reductions of up to 95% in its own production environment. For teams collecting continuous profiling around busy databases and services, these changes directly address storage cost reduction concerns that previously made long-term retention of high-resolution profiles impractical.
Stateless Queries and Lower Operational Overhead
Beyond storage, Pyroscope 2.0 is designed to simplify operations and handle the spiky query patterns typical of incident response. In the original architecture, queries were processed by stateful components that had to be sized for worst-case load, leading to idle capacity when the system was quiet. The new release makes the entire read path stateless: any querier can process any request, and the fleet can scale elastically with demand. This is especially relevant as LLM-based agents begin to query profiling data automatically during investigations, adding bursts of traffic with little baseline. Operational complexity is also reduced: the segment writer is now diskless, the store-gateway component has been removed, and Grafana reports that upgrades which once took 8–12 hours can be completed in minutes. For teams already stretched running large database environments, fewer stateful services and simpler rollouts are significant advantages.
Continuous Profiling for Large Database Environments
Database-heavy architectures generate complex performance profiles: slow ORMs, inefficient query plans and CPU-hungry indexing jobs can surface intermittently and under specific workloads. Continuous profiling captures these events as they happen, instead of relying on a lucky debugger session. Pyroscope 2.0’s optimized storage model and real-time querying allow teams to retain detailed CPU and resource usage data over longer windows, making it easier to correlate database spikes with application behavior. New capabilities enabled by the architecture—such as fleet-wide metrics derived from profiles, inspection of individual profile instances and heatmap visualizations over time—support comparative analysis across services and deployments. This helps SRE and database teams detect regressions when new releases hit production, as seen in real-world use at organizations like Monzo and Uber, where continuous profiling is integrated into workflows for catching performance regressions before they trigger costly outages.
Open Standards, Ecosystem Fit and Enterprise Adoption
Pyroscope 2.0 arrives as continuous profiling is being standardized across the observability ecosystem. OpenTelemetry has introduced profiles as a core signal and recently marked its Profiles support as alpha, with Elastic donating its profiling agent. Pyroscope now natively supports the OpenTelemetry Protocol (OTLP) for profiling, allowing teams to route data through the same pipelines as metrics, logs and traces. This interoperability, combined with Pyroscope’s open-source model and hosted option in Grafana Cloud Profiles, positions it as an attractive choice for enterprises wary of vendor lock-in or high managed-service costs. Competing open-source solutions such as Parca take different technical approaches, while commercial offerings from Datadog, New Relic, Dynatrace, Sentry and CubeAPM provide fully managed stacks. For organizations already invested in Grafana, the Pyroscope 2.0 architecture aims to lower the barrier to adopting continuous profiling at scale without incurring prohibitive infrastructure overhead.
