When we started Query, we weren’t chasing buzzwords. We set out to solve a painful, persistent problem in security: how to get answers from the data you already have without needing to move it, centralize it, or rebuild pipelines every time your environment changed. We believed then, as we do now, that the right data at the right time can mean the difference between detecting a breach and missing one. If, as they say, context is king, then data is queen. You need both.
That belief led us to invent and patent our approach to Federated Search for security. It was, and still is, a fundamentally different way to interact with data. Unlike SIEMs or centralized logging solutions, we don’t ingest your data or force you to normalize it in advance. Query connects directly to distributed systems via APIs with read-only access, normalizes results on the fly using open standards like OCSF, and delivers answers to security analysts, threat hunters, and incident responders, fast (Velocity=DisplacementTime).
Over time, we’ve added a purpose-built query language (Federated Search Query Language, or FSQL), AI to automate mapping your data to our OCSF-based schema, and an LLM-powered copilot to help teams summarize and act on search results. We’ve stayed grounded in user needs while layering in the right technical advantages – AI, schema mapping, real-time enrichment and context – only where they meaningfully improve outcomes. Never hype for hype’s sake.
As the industry evolved and interest in architectures like data mesh and data fabric grew, people started comparing Query to both. We take that as a compliment. But it’s also prompted an important question: If Federated Search is our how, is our what a Data Mesh, a Data Fabric, or something else?
Data Mesh vs. Data Fabric
Both data mesh and data fabric are modern approaches to solving the problem of distributed data. But they come from different philosophies:
- Data Fabric is often a centrally managed integration layer using metadata and AI to automate how data is discovered, integrated, and delivered. It’s about consistency, governance, and automation.
- Data Mesh is a decentralized model where individual domains own and expose their data as usable “products.” It’s about scalability, agility, and empowering teams to work autonomously while still enforcing shared standards.
These concepts aren’t mutually exclusive, but the differences matter. Especially in cybersecurity, where data is highly fragmented, environments are constantly changing, and the need for speed is non-negotiable.
Normalized Access To Decentralized Data
Query doesn’t centralize data. That’s not a limitation. It is by design. Our Federated Search engine connects to wherever your security-relevant data lives: Lakes, cloud buckets, EDR tools, identity platforms, cloud logs, SaaS systems, and more. It allows analysts to query across all of them at once, without knowing each system’s syntax or schema. It enriches and normalizes results on the fly. You can interact with the results, using a browser, our copilot, an app in Splunk, APIs, or even through a Model Context Protocol (MCP) server.
In a practical sense that means:
- No brittle ETL pipelines
- No duplicative storage costs
- No long onboarding projects for new data sources
You just connect and go. You ask a question. You get a complete data-driven answer.
It’s not about centralization. It’s about access. It’s about answers from your data. And that’s why, after reasoning through both models, we believe Query most closely aligns with the concept of a security data mesh.
Why Data Mesh?
Here’s how Query compares to each model:
| Feature | Data Fabric | Data Mesh | Query Alignment |
| Data centralization required? | Sometimes (for control/metadata) | No | ❌ No centralization |
| Governance model | Centralized and automated | Federated across domains | ✅ Federated |
| Access model | Unified via orchestration layer | Self-serve, domain-owned | ✅ Self-serve |
| Schema model | Central semantic layer | Domain-specific, federated | ✅ Normalized at runtime |
| Fit for live, distributed security data | Moderate | Excellent | ✅ Direct match |
| Primary user benefit | Automation and consistency | Agility and access across silos | ✅ Fast answers, low friction |
| Best match for Query | ❌ Partial | ✅ Full | ✅ Mesh is the match |
In security operations, data is inherently federated. Cloud logs are (mostly) managed by DevOps. Identity logs live in IT. SaaS data might be managed by a business unit. Trying to force it all into a single system is slow, costly, and often incomplete.
Our approach respects those boundaries while making the data usable. We normalize results at query time, returning one complete data set normalized to the Open Cybersecurity Schema Framework (OCSF). We utilize AI-powered schema mapping for dynamic data sources. We expose data as usable entities through FSQL and visual tools. That’s a data mesh, purpose-built for security.
The Engine Behind the Mesh: Federated Search
Here’s the key point: data mesh is the architecture, but Federated Search is the engine that makes it usable. Without Federated Search, a data mesh is just a set of scattered sources. With it, you can:
- Investigate across lakes, EDR, identity, and cloud tools in seconds
- Run threat hunts without pivoting between 10 browser tabs
- Reduce SIEM and storage costs by querying data in place
Add in AI copilots, automated schema mapping, and real-time enrichment, and you get an AI-powered security data mesh. One that analysts actually want to use.
Federated Security
This is what we mean when we talk about Federated Security, a model where the tools, data, and people you already have can work together more effectively. It’s about:
- Data access without data movement
- Answers without pivots and friction
- Context without complexity
We don’t just believe this is a better model. We’re seeing it in action every day, across security teams using Query to move faster, reduce cost, and improve their security outcomes.
Change Is Constant
Call it what you want – Federated Security, AI-powered data mesh, unified access layer – what matters is what it does: it gives security teams the ability to answer critical questions using all their data, wherever it lives. No pipelines. No blind spots. No waiting.
That’s what we’ve been building all along. And we’re just getting started. What we call Query will continue to evolve, just as our technology evolves to meet the real-world challenges security teams face every day. It’s not about what it’s called. It’s about what it enables you to accomplish.
