I'm building Osquil, a schema-aware query workbench for osquery

I've been working on Osquil, a schema-aware workbench for osquery. The first version is close, and before I publish it I want feedback from people who actually use osquery.

If you've used osquery for more than a week, you probably know the drill. You open osqueryi, type .tables, and stare at 200+ table names with no autocomplete, no column hints, and no clear idea what half of them return until you SELECT * and hope. You Google "osquery processes table columns" again. If you need to share results, you end up copying output around or piping it into something else.

osquery itself is great. Turning the OS into a queryable database is still one of the better ideas in security tooling. But writing queries against it often feels rougher than it needs to, especially when you're moving between tables, docs, and terminal output.

So I started building Osquil around the thing that kept slowing me down: the schema.

The editor knows the schema

The hard part of osquery usually isn't SQL. It's remembering which table has the data, which columns exist on which platform, and which tables need root or can be expensive to run. Nobody has all of that memorized.

The editor runs on CodeMirror and uses the osquery schema for autocomplete. It suggests tables, columns, and types as you type. There's also a searchable table and column browser in the sidebar, with the table docs next to the query, so you don't have to keep jumping back to the osquery website.

It also catches obvious column mistakes before the query runs. That sounds small, but after enough failed queries because of a typo or a platform-specific column, it starts to matter.

A query library, not a blank page

An empty SQL editor in front of a 200-table schema can be awkward even if you know SQL. So I'm adding a small library of detection and incident response queries for things like persistence mechanisms, suspicious processes, network connections, malware indicators, and USB history.

Each query has a short note explaining what it checks and why. These aren't meant to hide SQL from you. They give you a starting point, and you edit from there once you see the pattern.

Results you can work with

The result grid is intentionally boring: sort, filter, per-column search, resizable columns, copy a cell or row, and export to CSV or JSON.

That's the kind of stuff I miss most when using osqueryi directly. During an investigation, the query is only half the work. The other half is pivoting through the results, checking one weird row, and sending someone else a clean CSV without spending five minutes reformatting terminal output.

Plain English to SQL

This is the part I'm still treating carefully.

Because the schema is already structured, Osquil can give an LLM real table and column context instead of asking it to guess from memory. In theory, you should be able to type something like:

"Show USB devices plugged in during the last hour"

and get a real osquery SQL query back, using the right table and timestamp logic.

I don't want this to be a magic chat box that makes confident nonsense. The useful version is narrower: take a plain-English question, ground it in the actual osquery schema, generate a query, and let you inspect or edit it before running anything.

Charts and a process tree

I'm also experimenting with lightweight visuals where a table is not the best view. Simple charts can help with numeric columns, and a process tree for the processes table seems much more useful than staring at flat PID and PPID columns when you're looking for suspicious parent-child relationships.

Before I publish the first version

This started as a local tool for myself, but the more I build it, the more I wonder whether it should stay a focused local workbench or grow into a broader hunting and incident response workbench.

If you use osquery, I'd like to hear where this would actually fit into your workflow:

• What part of using osqueryi annoys you most?
• What would make you reach for this instead of the terminal?
• Should it stay focused on local query writing, or eventually plug into Fleet or a similar setup?

I'd rather hear that before I publish the first version than guess in the wrong direction.