The framework behind the query language

(or “Solved problems and how we solved them”)

I used to think data querying was a solved problem. But, as with many topics you dive into as a Product Manager, you learn the same lesson again and again: things are always more complex than you can imagine.

Continuing with our “moving your apartment” theme for this launch week, this post is all about the electricity and plumbing. The invisible infrastructure that must work perfectly, even though you rarely think about it.

While preparing to build our migration tool from legacy vendors to groundcover, we had to revisit our entire querying framework; making sure every edge case was handled, and that we could translate any query from other observability vendors into groundcover’s query languages.

It required finding the right balance between respecting the constraints of other vendors and reimagining things the groundcover way - modern, efficient, and built to last.

Mapping the use cases and choosing the paths

This effort was part of the ongoing “Dashboards and Data Viz” track we started over a year ago—this time focusing on the data layer itself.

Under the hood, groundcover uses ClickHouse for Logs, Traces, and Events, and VictoriaMetrics for built-in and custom metrics.

For metrics querying, the path was relatively clear. We knew MetricsQL was the right choice— it’s powerful, expressive, and perfectly suited for our needs.

But we didn’t stop there. We took a brave pill and built a MetricsQL query builder that can seamlessly switch between builder and code modes. That means our frontend now speaks MetricsQL fluently and provides the intuitive, flexible UX we aim for.

For logs, traces, and events, things were less straightforward. Since we’re dealing with SQL-based data sources, we had to figure out the optimal way to let users (and their AI agents) query this data, build monitors, and create dashboards on top of it.

We really admired what Victoria did with LogsQL and used it as an inspiration for our own middleware query language - sitting between ClickHouse and the user.

LogsQL is minimalistic, clear, and built with observability in mind. It supports both simple filter-based queries (used in our native pages) and more complex analytical queries (used in dashboards and monitors).

We started by designing our dream backend framework—making sure it covered all existing use cases in groundcover (and even a few future ones). Then we built a frontend compiler/parser, migrating all our native pages, dashboards, and monitors to speak the same language.

Now, our entire platform speaks the same language.

There were countless deep-dive sessions - debating every byte, every separation between FE and BE logic, every optimization for niche edge cases. All of this to ensure we built something durable that just works.

We optimized our frontend for 95% of customers’ use cases and invested heavily in providing code mode for both MetricsQL and the groundcover Query Language, so the remaining 5% are fully covered too.

The appetite just grew

The more we built, the hungrier we got. We realized just how powerful a good query language can be.

We’re already exploring how to expand its reach. From RUM session analytics to security use cases, all powered by the same underlying query framework.

Apparently, this wasn’t a solved problem after all.

But we are confident we’ve built a pretty good solution.