No(more)QL

A career in Queries

Back in the noughties, I changed my career and joined a niche database company specializing in XML data management. The company had a great product that helped some highly innovative companies achieve extraordinary things with unstructured content at scale. The biggest hurdle was the query language. Developers and DBAs had to learn XQuery to realize the platform's power. While there was a lot of buzz around XQuery at the time, there weren’t many experts in the market. It was a learning curve that many weren’t interested in climbing. And that's how my career in queries began. In the years since, I’ve had to learn multiple new technologies, each with its bespoke query language. Getting started with new query languages is relatively easy, but using them effectively at scale can require a deep understanding of schema, database architecture, and distributed programming.

Hello ObsQLs!

When I joined the world of Observability, I wasn’t surprised to find yet another crop of domain-specific query languages. After all, you don’t build beautiful dashboards without a good query or two. I call these “Obs-Squeels”. (Who knows, maybe it’ll catch on.) Monikers aside, the problem is the same — powerful tools gated by steep query language learning curves. If you don’t speak the language fluently, you’re stuck depending on someone who does. Query syntax is the lens through which you understand your system. If that lens is cloudy — or worse, inaccessible — so is your Observability.

The Hidden Cost of ObsQLs

The surface-level cost is easy to see: time spent learning syntax, onboarding new team members, and deciphering cryptic errors when a bracket’s in the wrong place. But the deeper costs are more subtle. First, queries don’t scale across teams. In most organizations, a small group of power users becomes the de facto query-writing team. Meanwhile, everyone else relies on prebuilt dashboards or copies and pastes old queries without really understanding them. This bottleneck slows down incident response, root cause analysis, and experimentation. Second, queries create knowledge silos. The nuance of a good query often lives in one person’s head. When that person leaves—or simply takes PTO—the context disappears. You’re left with a broken panel, a saved search you don’t trust, or worse, a missed alert. Third, queries assume you know what to look for. Most ObsQLs are great for answering specific questions like “What’s the average latency on this endpoint?” But they’re not great at telling you what to ask in the first place. That’s a strict limitation when trying to detect unknown unknowns, such as rare crash loops or subtle regressions in user journeys. Finally, there's the simple truth that query languages are a barrier to entry. Even experienced engineers often avoid touching them unless absolutely necessary. So when evaluating observability tools, it’s not just about power—it’s about accessibility. Can the entire team participate in understanding what’s happening? Or is that power locked behind syntax?

Hello NoQL Workflows

The bitdrift solution to this problem is no query language at all! Or as I like to say, NoQL (OK, OK, I’ll stop trying to coin new industry buzzwords!) Instead of pushing logs to a backend for querying, the bitdrift Capture SDK logs everything on the device. Instead of queries, developers use Workflows that define the telemetry they need and when they need it. Workflows can be pushed out to devices in seconds, and those devices immediately start returning metrics, logs, sessions, and crash reports. There is no expensive log store and no need to worry about lengthy mobile release cycles that typically take weeks or months. In my last blog post, I examined a real-world example of how a straightforward workflow was employed to resolve a surge in API errors. Today, I’d like to show you how easy and intuitive it is to create these workflows using the NoQL bitdrift UI. Imagine we’re deploying a new feature to our home design mobile application. We aim to compare the JVM crash rates in a treatment group with those in a control group. Additionally, for the treatment group, we want to investigate the root cause of any JVM crashes. To achieve this, we can create a simple workflow similar to the one shown in Figure 1.

Let’s break this down. Workflows comprise a sequence of matchers that define conditions (colored green) and actions to take when those conditions are met (colored purple). Anyone can build these using a simple drag-and-drop UI that supports keyboard commands, such as copy and paste, to accelerate the creation process. When we hit the “Deploy” button, workflows are compiled into a finite state machine and pushed out to every device in your fleet. The SDK on each device then evaluates the conditions against the events generated on the device and performs the actions when the conditions are met. Here’s what’s happening in each labeled step in Figure 1.

1. This box is an example of a generic match, which you can use to match any field in a log or event, including custom fields. In this example, we are matching devices in our control group.
2. We want to count all the devices in the control group, so we link the match to an action called “Plot Counter Chart.” This tells the device to create a counter metric and send it back to bitdrift. This is very efficient because the device only sends a single metric rather than an entire log.
3. This generic match identifies devices in the treatment group. We also want to count these devices, so we link this match to the same counter-chart action as the first generic match. Note how we assign a label name to each link that defines how the counts will be labeled on the resulting chart.
4. Here, we are adding a second match condition to the treatment group only. This matches devices in the treatment group that experienced a fatal JVM issue. This is an example of a default event, one of many that bitdrift provides out of the box. Default events are common mobile events that can impact mobile app performance.
5. In this step, we create a second counter chart to plot the count of JVM crashes in the treatment group.
6. In this step, we ask the device to send the entire session in which the crash happened so that we can investigate it using bitdrift’s session timeline, session replay, and span views.

To view the charts generated by this workflow and examine the sessions collected from our crashing devices, please visit our sandbox.

Wrapping Up: NoQL Means No Barriers

Workflows don’t just eliminate the need for queries—they eliminate the friction that comes with them. There is no syntax to learn. No tribal knowledge. No backend sleuthing. Just clear, declarative workflows that run where the issues happen—in the app on the device. In a world where debugging mobile issues can take days or weeks, that clarity is everything. And more importantly, it’s accessible. Anyone on the team—not just backend experts or observability power users—can build a workflow, share it, iterate on it, and learn from it. I should acknowledge that LLMs are starting to improve the usability of tools built around query languages—and that’s a big deal for teams long stuck behind steep learning curves. At bitdrift, we’re exploring how those same advances could make workflows even more intuitive and accessible in the future. Stay tuned for more on our AI strategy in future posts. I’ve spent my career navigating the shifting sands of query languages. And while they’ll always have their place, I’m ready for something better—something more intuitive, inclusive, and immediate. I used to work in the NoSQL space. Now, I work in the NoQL space.