Polar Signals is Joining Dash0

Today I'm excited to share that Polar Signals is joining Dash0. The entire team is coming along, and so is everything we've built: the profiler, Great Lakes, and Parca.

tl;dr Polar Signals is being acquired by Dash0. Nothing changes for Polar Signals Cloud users today, your product and support continue exactly as they are. Parca stays open source and we keep maintaining it. Over the coming months, continuous profiling becomes a native part of Dash0's OpenTelemetry-native platform, and Great Lakes becomes the storage engine underneath it.

It started at a dinner in Berlin

Mirko and I had crossed paths plenty of times before. Adjacent booths at KubeCon, the usual hallway shop talk. But the conversation that actually led here happened more or less by accident: we ended up seated next to each other at a dinner in Berlin, for the inception of the Signals conference.

Mirko started talking about the problems that come with running ClickHouse at Dash0's scale, the cost curve, the performance ceiling, the operational sharp edges. I mentioned, mostly in passing, that we were five iterations deep into a database built for exactly this shape of problem.

The more we talked, the more obvious it got that we'd been working toward the same thing from opposite ends. Dash0 had built an OpenTelemetry-native platform with metrics, logs, and traces already connected, and was missing the signal that tells you what the code was actually doing. We had spent years building exactly that signal, plus the storage engine to make it happen, and we were already planning to build the rest of the platform around it.

Yes, we built a database. In fact, several.

If you've read this blog before, you know the story, and you know I've been asked "why would you do that to yourself" more than once. Mirko asked it too, the first time we discussed it.

The honest answer starts with Prometheus. Ten years of maintaining and working with Prometheus taught me that the most valuable thing about it is what it doesn't do: it doesn't force a data model onto you. You attach whatever labels make sense for your organization, and you query by them later. I believe it is a big part of why it won.

Profiling data pushes that idea to an extreme. Every stack trace sample is essentially unique, so you're dealing with naturally unbounded cardinality, and you still want to filter and aggregate across every dimension arbitrarily. Our position was always that every key we see in the data should become a real column you can query. Nothing off the shelf could give us that, at least nothing available to us or commercially viable at the time.

So we built it. Four times before we got it right, which I'll happily admit. The first two never left prototype status. The third and fourth, which most of you know as FrostDB, got the fundamentals right: columnar, Parquet, Apache Arrow, but we'd painted ourselves into corners we couldn't engineer our way out of. A couple of years ago we made the call to start over one more time, with everything we'd learned.

That fifth one is Great Lakes, and it packs all the latest database research from academia combined with our operational experience from our years in the Prometheus, Kubernetes, and CoreOS ecosystems.

Great Lakes will become the storage engine behind SignalStore at Dash0, replacing ClickHouse over time. This is the part I find genuinely exciting: a database we built for profiles, running every signal. Metrics, logs, traces, and profiles in one engine, one query language, all of it correlated. That's the thing we've wanted to build for years, and now there's a platform to build it into.

What changes for you today: nothing

Polar Signals Cloud customers. Your product, your data, and your support continue exactly as they do now. Same profiler/agent, same UI, same MCP endpoint, same people answering your tickets. There is nothing you need to do. If and when anything does change for you, you'll hear it from us directly and ahead of time.

Parca users. Parca stays open source, and we keep maintaining it. The team that has been shepherding it, including the work merging many things that have made Parca-Agent unique into the OpenTelemetry eBPF profiler. Dash0 is an OpenTelemetry-native company, so if anything our upstream work gets easier to justify, not harder.

Everyone. The GPU work continues. Continuous CUDA profiling in production, PC sampling with stall-reason attribution, all of it.

What's coming

• Continuous profiling native in SignalStore. CPU, memory, and GPU visibility, correlated with the traces, metrics, and logs already in Dash0. Click a slow span, see what the CPU was actually doing during it.
• Auto-Tune. An Agent0 routine that reads your profiling data on a schedule and opens pull requests for the optimizations nobody got around to, with the profiling evidence attached.
• SignalControl. Profiling granularity that steps up automatically when something anomalous is happening, so you get depth when you need it without paying for it constantly.
• Great Lakes underneath all of it. Better scale, better cost, and deployment and security architectures that weren't possible before.

Thank you

To our investors who backed us when there was little more than an idea, to our customers, who trusted a profiler in production when it was still a slightly unhinged idea to use eBPF for anything but networking. To the Parca community and contributors, and to everyone in the Prometheus, Kubernetes, and CoreOS orbits who shaped how this team thinks. To the team itself, the Polar Bears, who rebuilt a database from scratch four times and then did it a fifth time properly.

We spent years building the best continuous profiler we could. Now we get to put it where it always belonged, next to everything else.

More soon,

Frederic