Grafana Pyroscope 2.0: Continuous Profiling with Direct-to-Object-Storage Architecture

What Pyroscope Solves and Who It Serves

Pyroscope addresses the problem of performance issues that only appear in production, where you cannot attach a debugger. It collects profiling data continuously, so you can inspect CPU, memory, and I/O usage at any point in time, down to a single line of code. The typical user is a platform or SRE team that needs to reduce resource consumption proactively, or respond to an incident reactively by identifying the exact function causing a bottleneck. The README positions it as a tool for both proactive optimization and reactive debugging. It is not a tracing system or an APM; it focuses solely on profiling data, which makes it complementary to those tools.

The v2 Architecture: Profiles Straight to Object Storage

Pyroscope 2.0 makes the v2 architecture the default. The key change is that profiles are written directly to object storage, removing the need for in-memory ingesters and local disks. The write path routes profiles by service and writes them straight to object storage. Compaction workers then merge small segments into larger blocks in the background. The read path fans out queries across object storage to build flame graphs in Grafana Profiles Drilldown. This design simplifies operations because you do not have to manage ingester state or worry about local disk failures. It also lowers resource usage at scale, since the server does not hold all data in memory. The trade-off is that you now depend on object storage latency and availability, and you must run compaction workers as a separate concern. The README states that existing v1 deployments can opt in via a flag and migrate without data loss, which suggests a careful transition path.

Getting It Running: Docker, Homebrew, and Binary

The quick start is straightforward. With Docker, you run `docker run -it -p 4040:4040 grafana/pyroscope`. That starts the server on port 4040, and you can then send data to it. On macOS or Linux, you can use Homebrew: `brew install pyroscope-io/brew/pyroscope` followed by `brew services start pyroscope`. For a binary, you download the archive from the latest release, unpack it with `tar xvf pyroscope_*.tar.gz`, and run `./pyroscope`. The README points to the Get started guide and server documentation for Kubernetes/Helm, Linux packages, and full configuration options. Notably, the quick start does not mention configuring object storage; that is presumably covered in the server documentation, which you must consult for production use.

Sending Data: SDKs, Alloy, and OTLP

Pyroscope accepts profiling data through three main paths. You can use language SDKs for Go, Java, Python, and others, which push profiles directly to the server. Alternatively, Grafana Alloy can pull or push profiles, acting as a collector. The third path is OTLP from OpenTelemetry-compatible sources, such as the OpenTelemetry eBPF profiler. This flexibility is a strength: you can instrument applications with SDKs for fine-grained control, or use eBPF for zero-code profiling of running processes. The README includes a table with links to language-specific documentation and examples, so the SDK coverage is clearly a priority. However, the README does not detail the exact SDK API calls or configuration keys; you must follow the linked documentation for that.

Visualizing Profiles with Grafana Profiles Drilldown

The primary visualization tool is Grafana Profiles Drilldown, formerly Explore Profiles. It is described as queryless, meaning you do not write queries to explore data; you navigate through the UI. In Grafana Cloud or OSS, Profiles Drilldown is pre-installed and is the default way to explore profiles. This tight integration with Grafana is a major selling point, but it also means Pyroscope's value is tied to Grafana. If you are not a Grafana user, you would need to set up Grafana just for profiling, which may be overkill. The README mentions a live demo at play.grafana.org, so you can try the UI before committing.

Limitations and Failure Modes

Pyroscope v2's reliance on object storage introduces latency on the read path. Queries fan out across object storage, which can be slower than reading from local disk, especially for large ranges. The README does not mention any caching layer, so you should expect that flame graph loading depends on object storage performance. Another limitation is that the v2 architecture is new; the README announces it as a significant change, and while v1 can migrate, the migration is not automatic. If you are on v1, you must opt in and follow the migration guide, which implies effort and potential risk. Also, Pyroscope is AGPL-3.0 licensed, which has implications for companies that want to modify and distribute the server without open-sourcing their changes. The README does not discuss this, but the license is a real consideration for some organizations.

Alternatives and How They Differ

The most direct alternative is Parca, an open-source continuous profiling project from Polar Signals. Parca also stores profiles in object storage, but it uses a different storage format and has its own UI, not requiring Grafana. The key difference is that Parca is designed to be self-contained, while Pyroscope is deeply integrated with Grafana. If you already use Grafana, Pyroscope offers a smoother experience because Profiles Drilldown is built in. If you do not, Parca avoids the Grafana dependency. Another alternative is the OpenTelemetry profiling signal, which is still evolving; Pyroscope supports OTLP, so you can use OpenTelemetry collectors, but the storage and UI are Pyroscope-specific. The choice often comes down to whether you want a Grafana-centric workflow or a standalone tool.

Maintenance and Upgrade Considerations

The v2 architecture reduces operational burden by removing ingesters, but it adds compaction workers that run in the background. You must monitor these workers to ensure they keep up with incoming data. The README does not specify resource requirements for compaction, so you need to test at your scale. Upgrades are frequent: the repository shows releases v2.1.2, v2.2.1, and v2.3.0 within a short period, indicating active development. Each upgrade may bring changes to the v2 architecture, so you should review release notes before updating. The migration from v1 is a one-time cost, but it is documented, which helps. The AGPL-3.0 license means that if you modify the server and offer it as a service, you may need to release your modifications. That is a legal consideration, not a technical one, but it can affect adoption in some companies.

Editorial conclusion

Adopt Pyroscope if you run Grafana and need line-level profiling across multiple languages with a queryless UI. It is a strong fit for teams already using Grafana Cloud or OSS and willing to manage object storage. Avoid it if you need a standalone dashboard without Grafana, or if you cannot handle the operational overhead of S3-compatible storage and background compaction. Before adopting, verify your object storage compatibility and retention policies, and test the migration path from v1 if you are upgrading. The v2 architecture removes ingesters, but the compaction workers and query fan-out are new operational components you must size and monitor.

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes