What Is Osquery? The SQL Framework for Endpoint Visibility

The hardest part of endpoint security is not detection. It is knowing what is true on the machine right now.

So, what is osquery? It is an open source agent that exposes an operating system as a relational database. Instead of a dashboard someone else designed, you get SQL tables: processes, listening_ports, users, installed_applications, and more than 280 others. You write a query, the agent reads live system state, and you get rows back. It runs on Windows, macOS, and Linux with the same query language on all three.

That design sounds almost too plain to matter. It matters because every security function downstream of visibility (vulnerability triage, incident response, compliance, threat hunting) is bottlenecked by one question: what is actually on the endpoint. Osquery answers that question with evidence rather than inference.

What is osquery in practical terms?

Picture the moment a new vulnerability drops and your CISO asks how exposed the company is. With traditional tooling, you wait for a scanner window or a vendor signature update. With osquery deployed, someone types:

Run that across the fleet through a fleet manager and the exposure question is answered in minutes, with exact versions, from the package database itself. Nobody guessed. Nobody waited for a scan window. That speed difference compounds: a team that answers ten of these questions a month, saving even four hours per question, recovers 40 hours of engineering time. Half a work week, every month, from one agent.

The project has real history behind it. Facebook released osquery in October 2014, Windows support landed in 2016, and the Linux Foundation has stewarded it since 2019. Releases continue steadily; version 5.23.1 shipped in June 2026 per the osquery release history. Airbnb, Dropbox, Netflix, and Uber were early production adopters. This is not a research toy.

How does osquery actually work?

Osquery embeds SQLite as a query engine, but the tables are virtual. Nothing sits in a database waiting to go stale. When your query references processes, the agent reads the kernel's process list at that moment and presents it as rows. SQL is the interface; the operating system is the data.

Two binaries cover the two ways teams use it:

• osqueryi, the interactive shell. Open a terminal, type SQL, get answers. Perfect for investigations and learning. No configuration needed.
• osqueryd, the daemon. It runs your queries on a schedule and logs only what changed between runs. Point the output at your log pipeline and you have continuous, low noise fleet telemetry.

Performance is governed by a watchdog that restarts the worker process if it exceeds 200MB of memory or holds CPU above 10 percent, per the official osquery flags documentation. A bad query gets killed; the host keeps serving traffic. Those defaults are why osquery has a reputation for being a polite tenant on production systems.

Beyond snapshot queries, osquery also supports evented tables that record activity as it happens rather than sampling on an interval. On macOS these are built on Apple's EndpointSecurity framework, which osquery adopted in version 5 after Apple deprecated kernel extensions. On Linux, audit based tables capture process and socket events. Events close the gap where short lived activity hides: a process that runs for two seconds between scheduled queries is invisible to snapshots and fully visible to events. The tradeoff is volume. Evented tables on busy hosts produce a lot of rows, so most teams start with snapshots and add events deliberately.

A worked example makes the join model concrete. Suppose you want every process listening on an external interface, with the user who owns it. That is three tables stitched together with ordinary SQL: processes for identity, listening_ports for exposure, users for ownership. No vendor had to anticipate the question. The schema is the API, and the schema documentation is public, versioned, and searchable. When you are ready to move past single table selects, our practical guide to writing osquery queries covers the joins, constraints, and scheduling decisions that matter in production.

What questions can osquery answer?

A sample of questions teams answer with single queries or simple joins:

• Which machines have a process listening on all interfaces, and what binary is it?
• Which laptops have disk encryption disabled?
• What browser extensions exist across the fleet, and which appeared this week?
• Which hosts have a cron entry or startup item that changed since yesterday?
• Which servers run a package version affected by this morning's advisory?

The pattern behind all five: correlate live state, filter to what should not exist, and alert only on change. The last question is the one with board level weight right now. The 2026 Verizon Data Breach Investigations Report found vulnerability exploitation became the leading initial access vector at 31 percent of breaches, ahead of credential abuse for the first time in the report's history. Knowing your installed software, precisely and continuously, stopped being hygiene and became front line defense.

Notice what all these questions have in common: none of them require new collection infrastructure. The same agent, the same schema, and the same query language cover inventory, exposure, persistence, and compliance. Compare that with the usual alternative, where each question belongs to a different tool with a different agent, a different console, and a different renewal date. Four agents at even 150MB of memory each is 600MB per host doing overlapping work. Tool consolidation is usually a procurement fantasy. At the visibility layer, osquery makes it an engineering reality.

Where does osquery fit in a security program?

Four functions get the most value, and each uses the agent differently.

Vulnerability management uses osquery as ground truth for what is installed. Scanners infer versions by probing from the network, which is why they generate findings for software that is not there and miss software that is. Reading the package database directly removes the guesswork, and endpoint context (is the vulnerable library actually loaded, is the service exposed) turns a raw finding into a decision. That distinction is the core of context aware prioritization, and it is the difference between a backlog of thousands and a work list of dozens.

Incident response uses the interactive shell. When a responder needs to know what a suspicious process is doing, which hosts have the same binary, or what changed on a machine in the last day, osqueryi answers in seconds without installing anything new mid incident. Fleet wide queries turn "is this anywhere else" from a day of work into a coffee break.

Compliance uses scheduled queries as an evidence factory. Disk encryption status, password policy, patch level, and unauthorized software are all queryable, which means audit evidence is generated continuously instead of assembled in a panicked week before the assessment.

Threat hunting uses differential results. A query that watches startup items, kernel modules, cron entries, or browser extensions reports only when something changes. Most days it says nothing. The day it speaks, you want to be listening.

What osquery is not

Osquery observes. It does not block malware, quarantine hosts, or fix what it finds. It is not an EDR replacement, and teams that deploy it expecting prevention are buying a microscope and expecting a scalpel.

It also does not interpret. A schedule of 50 queries across 5,000 hosts produces a river of differential logs, and raw rows do not triage themselves. Someone, or something, has to read the output and decide what matters. That analysis gap is the real cost of an osquery deployment, and it is the gap where most of the current innovation sits, including the approach we describe in machine learning in endpoint telemetry. Artemes AI exists for exactly this reason: our platform combines deep endpoint context with an AI judgment layer that reads system state to decide which findings are real and what the fix is. Collection gathers truth. Something still has to think about it.

What does osquery cost to adopt?

The license is free. The adoption is not, and pretending otherwise is how deployments stall. Budget for three real costs.

Query engineering. Someone has to translate your security questions into SQL and maintain the schedule as the environment changes. This is not hard work, but it is ongoing work, and it needs an owner. A schedule without an owner rots into a set of queries nobody remembers writing, feeding a log stream nobody reads.

Pipeline and storage. Differential logging keeps volume sane, but a fleet of thousands still produces data that has to move, land, and be retained somewhere. The costs are modest compared to commercial telemetry products, and they are not zero. Measure on the pilot group before you extrapolate.

Analysis. This is the big one, and the one most planning documents skip. Rows do not read themselves. If your plan for the output is "an analyst will look at it," multiply your analysts' loaded hourly cost by the hours of looking and see if you still like the plan. If the answer is automation, decide what automation before you deploy, not after the logs pile up.

Against those costs, weigh what the agent displaces: scanner blind spots, manual inventory, audit evidence scrambles, and the multi hour fleet questions that become single queries. For most organizations past a hundred endpoints, the arithmetic lands firmly in osquery's favor. It just lands there faster when the costs are named up front.

How do you get started?

Install it on one machine and open the shell. The full walkthrough for every platform is in our guide to installing osquery on Windows, Linux, and macOS, and the complete table reference lives at the osquery schema site. When you outgrow one host, the deployment, scaling, and vulnerability management story is covered in our definitive osquery handbook, and our query library gives you a working starting schedule.

Frequently asked questions

Is osquery free to use commercially?

Yes. It is open source (dual licensed under Apache 2.0 and GPL), hosted by the Linux Foundation, and free for any use. Costs come from deployment effort and log handling, not licensing.

Does osquery slow down endpoints?

Not with default settings. The built in watchdog caps worker memory at 200MB and sustained CPU at 10 percent, and terminates queries that exceed the limits. Overhead issues almost always trace to one badly scheduled query, which the watchdog contains.

Do I need to know SQL to use osquery?

Basic SELECT, WHERE, and JOIN cover most real work. If you can filter a spreadsheet, the learning curve is a weekend. Community query packs also provide hundreds of prewritten queries to adapt.

Is osquery an EDR?

No. It has no prevention or response capability. It complements EDR by answering arbitrary questions about system state that detection products were not built to ask.

The takeaway

If your team cannot currently answer "what is running, listening, and installed on every host we own," osquery is the cheapest credible way to fix that, and the skills transfer because it is just SQL. Install it on one machine this week, run five queries, and see how many questions you have been living without answers to. Then decide what deserves a schedule.