Query data with greater flexibility using LimaCharlie Query Language (LCQL)

Most security tooling forces a quiet, expensive choice. You keep telemetry because you might need it later, but the systems that let you actually interrogate that data live somewhere else, behind a license you pay for whether or not you ever run a query. LimaCharlie retains a full year of telemetry by default, which on its own only deepens that problem: a year of data you cannot easily question is a year of storage cost waiting for a reason. The LimaCharlie Query Language, introduced in this session by co-founder Christopher Luft and founder and CEO Maxime Lamothe-Brassard, is the argument that the data and the means to ask questions of it should not be two separate purchases. The interesting move is not that LimaCharlie added a query language. It is that the query language collapses the boundary between investigating the past and detecting in the present.

The data is already here; the friction was never the storage

Lamothe-Brassard frames LCQL as a layer on top of retention rather than a new product bolted on. He ties it directly to LimaCharlie's existing replay feature, which runs detection rules against historical data, then describes LCQL as the more open, ad hoc cousin of that idea, a way to query the data set the way you would in Splunk or the ELK stack. The reasoning is plain. The telemetry is already in the cloud, and LimaCharlie is increasingly the fabric where teams aggregate data from many different sources. Given that, the recurring tax of exporting data to a separate system just to ask a question of it is exactly the thing worth eliminating. LCQL exists to reduce the number of times you reach for another tool to interrogate data you already own.

That framing matters more for a service provider than a single-tenant shop. An MSSP or MDR running many customer environments does not want a second platform, with its own provisioning and its own bill, sitting between the telemetry and the analyst. Lamothe-Brassard is explicit that LCQL ships in two forms, and neither is a separate stack. It first ran inside the command line interface built on the Python SDK, where it has been available for a few weeks, and that path stays for the times the CLI is what you need. This session launches the web interface, deliberately kept close in implementation to the CLI so the two are interchangeable. The point is reach, not novelty: the same capability, wherever the operator already works.

Pricing that mirrors how investigation actually behaves

The economic design is where the philosophy gets concrete. LCQL is billed per query, not as a base subscription, and Lamothe-Brassard compares the model to Google Cloud's BigQuery. There is no large up-front cost to provision the way a self-managed Splunk or ELK deployment demands. The billable unit is the number of events scanned, which means the cost tracks the two dials an investigator actually turns: how far back in time the query reaches, and how wide a set of sensors it covers. Run little, pay little. Run a year across every endpoint, pay linearly for that.

What keeps usage-based pricing from becoming a source of dread is that LimaCharlie shows the cost before the query runs. When you press enter, the platform validates the query and displays a worst-case estimate. On the first live query, the amount actually charged came in slightly different from that estimate, which Lamothe-Brassard attributes to a handful of events that arrived in the last couple of minutes. The real saving shows up on larger queries, and the demo proves it later on a paginated DNS query, where the estimate ran quite a bit higher than what was actually charged. The mechanism is automatic pagination: a query that would match months of data does not bill you for the full range at once. You get the first slice and pay only for that slice, then page through more if you want it. For a provider pricing a service on top of this, predictability is the feature. You can hand an analyst the ability to reach across a year of a client's data without handing them an unbounded meter. And because LCQL is included in the free tier, a team can validate the workflow before it ever touches client billing.

There is one honest limit Lamothe-Brassard names rather than hides. Aggregating queries, the ones using count or grouping, cannot be paginated, because counting or grouping requires the full result set. Those scan everything they match. The estimate still tells you what that costs before you commit, which is the whole point of showing it up front.

A query language that is already a detection rule

The detail that makes LCQL more than a convenient search box is how closely it tracks the system operators already use. The query is a sequence of components separated by pipes, narrowing the data at each step: a time frame (an offset like the last 24 hours, or two dates), a sensor selector (tags, host name, platform, or a star for everything), the event types, a filter expression, and an optional projection that selects and renames fields the way a SELECT does in SQL. The filter operators are deliberately the same ones from the detection and response rule language, is, is not, contains, ends with, is tagged, is platform. An engineer who already writes rules in LimaCharlie does not learn a second syntax to start querying.

That shared vocabulary is not cosmetic, and the demo shows why. Under the hood, LimaCharlie applies your query as a detection and response rule against historical data, and the interface will show you that generated rule directly. So the workflow runs in one direction with no translation step: explore the past until a query surfaces the pattern you want (the demo filters network connections from unsigned processes, then counts DNS resolutions to .net domains grouped by domain), then export the rule that query already is and put it into production. Investigation and detection stop being separate disciplines with separate tooling. The same expression that answered "did this happen last month" becomes the thing watching for it next month. For a detection engineer at an MDR, that shortens the path from a hunch about a client's telemetry to a deployed detection across the fleet, and the per-field CSV export shown in the demo turns the same query into a client-ready artifact on the way out.

Strip away the demonstration and the claim underneath is about consolidation, not search syntax. The conventional setup treats retention, investigation, and detection as three things you buy and stitch together. LCQL treats them as one surface: the data is already here, the cost of asking is metered and shown before you spend it, and the question you ask is already the rule that answers it next time. For a provider whose margin depends on doing this across many tenants without a rack of separate tools, that consolidation is the value.