A note from Mirko Novakovic (Dash0) and Frederic Branczyk (Polar Signals)
We wanted to write this one ourselves, not as a press release, but as two founders telling you why this actually happened.
It started with a dinner in Berlin
We'd crossed paths before, booths next to each other at KubeCon, a bit of shop talk in the hallways. But the real conversation happened almost by accident: we ended up seated next to each other at dinner in Berlin for the inception of the Signals conference. Mirko mentioned the scale, performance, and cost challenges that come with running ClickHouse at Dash0's growing size. And Frederic mentioned, almost in passing, that Polar Signals was already five iterations deep into building exactly the kind of database Dash0 needed: Great Lakes.
That's the moment this deal was actually born. Not in a boardroom. At a dinner table, in Berlin.
Why build a database at all?
Mirko's first reaction, honestly, was "why would you do that to yourself?" Building a database from scratch is one of those ideas that sounds simple until you're the one doing it.
But Frederic had a good reason. Polar Signals grew out of the Prometheus world, where the whole philosophy is: don't force users into someone else's data model, let them tag things however makes sense for their organization. That idea is powerful for metrics, but profiling data pushes it to the extreme; every single stack trace sample is essentially unique. You still want to slice and filter and aggregate across all of it, arbitrarily.
Nothing off-the-shelf could do that at the level Polar Signals needed.
So they built their own. Four times, actually, before they got it right. The first two attempts never made it past the prototype stage. The third and fourth, internally nicknamed "FrostDB," got the fundamentals right - columnar, built on Parquet and Apache Arrow - but boxed the team into corners they couldn't easily engineer their way out of.
So a couple of years ago, they scrapped it and started over one more time.
That fifth attempt is called Great Lakes, and by all accounts, it's the one that finally clicked.
That's the backend Dash0 is now adopting to replace ClickHouse in SignalStore.
Besides the database, profiling was also a missing capability for Dash0. Mirko started his career as a profiling consultant and trainer - using Quest JProbe and JProfiler more than 20 years ago. Profiling is one of the most powerful tools for developers but rarely used, as it is time-consuming and complex. Profiling was only used on developer machines, like a debugger. But Google invented Continuous Profiling in production a few years ago and created a superpower for developers - and Polar Signals is probably the best tool out there, and in combination with AI Frederic and Mirko created a vision for a combined team that can create something unique in this space.
What profiling actually is (in plain English)
If you've never dealt with continuous profiling, here's the idea, explained the way Mirko put it: it's a bit like a flipbook. You take a snapshot of exactly what a program's call stack is doing, maybe a hundred times a second, and when you flip through those "frames," you get a moving picture of where your code is actually spending its time and resources.
The clever part is how Polar Signals captures those snapshots. Using eBPF, they can ask the Linux kernel to sample the stack every so many CPU cycles, without ever pausing the running process. That's what makes it safe to run continuously in production, with overhead so low (under 1% for CPU profiling) that most teams can't tell it's switched on. And they can do it for compiled languages like Rust or C/C++.
And because Polar Signals controls the entire pipeline down to the storage layer, they can do things generic databases can't: deduplicating repeated stack patterns, deferring symbolization (turning memory addresses into human-readable function names) until query time instead of storing it redundantly a million times over. It's the kind of optimization you only get to make when you own the whole stack.
The part almost nobody's doing yet: GPU profiling
This is the bit we're most excited about. Right now, GPU profiling tooling is basically nonexistent outside of single-machine developer tools. Nothing built for continuous, production-grade profiling of NVIDIA/CUDA workloads exists at scale, until now.
Polar Signals figured out how to trace the full picture: the CPU-side call stack that triggers a CUDA kernel, and then what happens inside that kernel itself, including why GPU threads stall, which turns out to matter more than almost anything else for GPU performance. When your hardware's sitting idle waiting on one lagging thread in a group, that's the thing worth fixing, not micro-allocations.
Given how much the industry is spending on GPU compute right now, even small optimizations here translate into serious money. One customer, Materialize, a database company already obsessed with performance, cut their AWS bill by 35% within hours of turning profiling on. Not because they were doing anything wrong. They'd simply never seen this data before aggregated over their entire infrastructure.
Why now, and why does AI change everything here
Profiling has always had a reputation problem. It's been the domain of the one senior engineer on the team who "gets it," with visualizations that look intimidating if you've never learned to read them. But the actual practice is pretty systematic: find the function that's burning the most resources, check whether that code path can be avoided or batched, and repeat.
That systematic nature is exactly what makes it a great fit for AI agents. They're already good at reading code and proposing changes; profiling just gives them ground truth to work from instead of guesswork. Point an agent at real profiling data via MCP, and it can go find the expensive code path and propose a fix, on its own.
That's the thread connecting this whole acquisition to where Dash0 is headed with Agent0: as more code gets written and operated by agents, those agents need real signals about what the code is actually doing, down to the line, down to the kernel, not just traces and metrics.
Combining the signals
While drinking another glass of wine at dinner, we also learned that we share the same vision for observability: Every signal (metrics, events, logs, traces, profiles) needs to be on one database, with a consistent query language and everything connected to create context - especially in the age of AI.
Today, you can easily see all the logs and events for a span and all the correlated metrics in Dash0, but what if you could also see all the details of that span from the profiles in production? You could see where the CPU is burned, or threads are stalled in a single, consistent view. Of course, with our unique UI, but also via MCP/CLI for agents.
What's actually coming
To be concrete about what this means for Dash0 customers:
- Continuous profiling, built into SignalStore. CPU, memory, and GPU visibility, down to the line of code.
- AutoTune. Agent0 will continuously analyze profiles and proactively open pull requests to reduce CPU and memory usage, without anyone having to look for the problem first.
- SignalControl. Profiling granularity adjusts automatically, stepping up detail when something anomalous happens, so you get depth exactly when you need it without paying for it all the time.
- Great Lakes as the new backend. Over time, this replaces ClickHouse in SignalStore, unlocking better scalability, performance, and cost efficiency, as well as deployment and security architectures that weren't possible before.
Welcome, PolarBears
Frederic and the whole Polar Signals team, plus the open-source Parca project they've built along the way, are now part of Dash0. This isn't just a product acquisition. It's a rare team: people who've spent years in the Prometheus, Kubernetes, and CoreOS communities, who've built (and rebuilt, and rebuilt again) some of the hardest infrastructure in observability.
We've been circling similar problems from different directions for a while. Now we get to solve them together.
More soon,
Mirko & Frederic
