
Open source continuous profiling software to debug performance issues
Explore the risks and possibilities with a prompt for ChatGPT, Claude, or your agent.
Pyroscope built an open-source continuous profiler: software that samples how production applications spend CPU time and memory, then turns those samples into flame graphs. Ryan Perry and Dmitry Filimonov founded the YC W21 company after encountering the limits of one-off profiling at Sensor Tower. By March 2023, the project had 7,200 GitHub stars, a hosted cloud product, and a Grafana integration.[1]
Pyroscope did not fail. Grafana Labs acquired it on March 15, 2023, merged it with Grafana Phlare, and made profiling a native part of its open-source observability stack and Grafana Cloud. The result validates the product thesis while exposing the standalone business problem: continuous profiling was valuable, but an observability platform could distribute it more efficiently as a fourth telemetry signal. The purchase price, consideration, and retention terms were not disclosed.
Perry and Filimonov had worked at Sensor Tower, where Perry held engineering roles before later working at Lion Studios/AppLovin and Filimonov led an engineering team. Their shared origin mattered because Pyroscope began with an operating problem rather than a speculative category thesis. Production profiling could reveal latency and cloud-cost waste, but available tools were difficult to deploy continuously and tended to focus on local debugging. On Launch HN, the founders summarized the desired behavior as running “a profiler 24/7 in production.”[2]
They turned that insight into an open-source product that required only a few lines of instrumentation, according to YC’s company profile. Pyroscope entered Y Combinator’s Winter 2021 batch and was officially founded in 2021, although TechCrunch later reported 2020. This report uses 2021 because both YC and Grafana use that year.[3] The evidence handoff does not establish how the founders first met beyond their shared Sensor Tower employment.
The initial wedge was developer-controlled software that stored profiling data locally and made flame graphs easy to compare across time. The company then widened language support, released packages for Python and Ruby, built a Grafana flame-graph plugin, added ad hoc and CI profiling, and launched Pyroscope Cloud in September 2022.[4] A 2021 seed round led by General Catalyst, with Harvard, SoftBank, SV Angel, and IU Angel Network participating, funded hiring to meet demand; the amount was not disclosed in the cited announcement.[5]
The available primary sources contain one short founder phrase suitable for verbatim quotation, but not the two complete founder quotes requested by the canonical report format. No founder podcast, long-form acquisition account, or negotiation history was located in the evidence handoff. Rather than reconstruct wording from summaries, this report records that gap.
Continuous profiling replaces a debugging snapshot with a moving record. An application agent or system profiler samples what code is running. Pyroscope ingests those samples, compresses them, and lets an engineer inspect flame graphs for a selected service and time range. That makes regressions visible: a team can compare a release against an earlier period, find a function consuming excess CPU, or connect expensive code paths to a trace.
The open-source server accepted data from language runtimes and tools including rbspy, eBPF, and Memray. Its language-agnostic storage engine made those inputs queryable through one interface.[10] The company expanded from continuous profiles into ad hoc investigations, trace-linked profiling exemplars, and CI/CD profiling. The last feature moved performance analysis earlier in the software lifecycle by comparing code before production.
Pyroscope Cloud drew a clear commercial boundary around the open-source product. The self-hosted edition used embedded BadgerDB and primarily scaled vertically. Cloud replaced that storage layer with distributed key-value infrastructure, added horizontal scaling and high-cardinality support, and sold operational benefits such as encryption, zero-downtime upgrades, support, and integrations with Honeycomb and Jaeger.[6]
Grafana completed the platform version of that idea. It combined Pyroscope’s agents, user experience, and cloud operating knowledge with Phlare’s distributed architecture. Grafana Pyroscope 1.0 changed the container image from pyroscope/pyroscope to grafana/pyroscope and targeted correlation across profiles, metrics, logs, and traces.[8] Pyroscope 2.0 later moved distributed deployments toward object storage and stateless reads, while adding profile-derived metrics, heatmaps, and inspection of individual profiles.[9]
Pyroscope targeted software teams operating production services where latency, compute cost, or regressions mattered enough to justify always-on measurement. Named customers reported by TechCrunch included Sensor Tower, Confluent, Line, and Plaid.[11] The open-source edition gave individual engineers and platform teams a low-friction entry point. Cloud addressed organizations that wanted the analysis without running a profiling data plane.
No credible standalone continuous-profiling market size appears in the supplied evidence. Treating the broader observability market as Pyroscope’s addressable market would overstate the case because profiles are one signal within that budget. The acquisition itself points to the more useful frame: profiling expanded the observability suite rather than remaining an isolated category.
The decisive competitive axes were profiling depth, deployment control, and distribution inside an existing observability workflow. Pyroscope had product depth and an open-source community. Grafana had dashboards, Cloud distribution, and adjacent metrics, logs, and traces. It also had Phlare, its own horizontally scalable profiling database. The acquisition therefore combined overlapping technical assets while removing the distribution gap.
TechCrunch identified the structural threat: profiling could become a feature inside larger observability platforms rather than a durable standalone category.[11] That is not evidence that Pyroscope’s product was weak. It explains why Grafana was a natural owner. An independent vendor had to sell, integrate, and operate another telemetry system. Grafana could place profiles beside data customers already collected and bill them through an existing account.
Pyroscope followed an open-source-to-hosted model. The free software created adoption and trust among engineers; Pyroscope Cloud charged for managed ingestion, storage, upgrades, security, and support. Public sources do not disclose Pyroscope revenue, pricing realization, margins, annual recurring revenue, or paid customer count. The seed amount is also unavailable, so a responsible burn estimate cannot be made.
Under Grafana, the economic model became explicit usage billing. Grafana Cloud Profiles measures consumption in gigabytes ingested, while the free tier included 50 GB of profile data and 14-day retention at general availability.[7] That aligns price with the cost driver, but it also creates pressure to control labels, profile types, and sampling because broader coverage raises ingestion volume.[12]
At the acquisition announcement, Pyroscope had 7,200 GitHub stars and named production customers, but no public revenue or paid-account figure.[1] The strongest evidence of product value arrived after the deal. Grafana said version 1.0 had been tested above 50,000 profiled instances and 6,000 unique profiles per second.[8] By 2025, Grafana Cloud’s 2.0 deployment was processing 19.5 petabytes of profile data.[9] Those are Grafana-reported operating metrics, not evidence of Pyroscope’s pre-acquisition revenue.
The wrong post-mortem would ask why Pyroscope died. Its code, category, and hosted product continued under Grafana. The useful question is why integration created more value than independence. Grafana’s announcement called profiling the fourth pillar after metrics, logs, and traces and said it would correlate profiles with those existing signals.[1] That distribution and workflow advantage is the structural mechanism.
Pyroscope had already tried to bridge the gap. It built a Grafana plugin in 2021, launched a managed cloud service in 2022, and added trace integrations. Those moves improved interoperability but could not give a five-person startup the installed base, billing relationship, or telemetry breadth of a platform. Grafana’s remedy was acquisition and merger, not shutdown. Within two and a half months it put Profiles into Grafana Cloud preview, and it reached general availability that August. The speed suggests the acquired product and team filled a prepared platform slot rather than entering a speculative incubation.
Grafana already had Phlare. Buying Pyroscope was therefore not simply a code acquisition. Grafana’s engineering account emphasized Pyroscope Cloud’s product breadth and highly available operation, while the merged roadmap combined those capabilities with Phlare’s distributed design.[13] Pyroscope contributed agents, developer adoption, a user-facing product, and experience selling a managed service. Grafana contributed an observability audience and a route to correlate profiles with other signals.
The counter-narrative is that an acquisition by a vendor with an internal competitor signals weak defensibility. The post-acquisition record cuts against that reading. Grafana retained the Pyroscope name, shipped a merged 1.0, migrated users to a new repository and image, and continued through a 2.0 architecture deployed in Grafana Cloud. The product identity changed owners, but the thesis gained scale.
The deal terms were undisclosed. No observed source establishes the price, consideration mix, investor return, founder retention package, ARR, or negotiation process. It is therefore impossible to classify the transaction as a financial home run, acqui-hire, or distressed sale. The defensible conclusion is narrower: it was a strategically coherent acquisition followed by rapid integration and sustained product investment.