Query

Name: Query
Brand: Query

Federated Search For Security Teams

Est 2018|Valuation $62.1M|Raised $19.7M|11 Ref Customers

LinkedIn 6K|Web traffic 3K|FTEs 45|HQ Atlanta, Georgia, US

MarketsSecurity Orchestration, Automation, and Response (SOAR)

Published Oct 15, 2026

01Common complaints

1. You need index-grade performance and consistent query latency - For investigative workflows demanding very fast, consistent search, a centralized index or data lake optimized for search may be more reliable than multi-API federation. 2. Your data sources have poor or limited search APIs - Federated search quality is limited by API design; if key sources only support limited filtering, results may be incomplete or slow. 3. You are a small organization with a simple stack and limited SIEM ingestion - With a listed $60K/year entry point on the marketplace, ROI may be weak if the organization lacks significant duplication or engineering toil to eliminate. 4. You require widely validated third-party reviews before purchase - The public review footprint is limited in the sources reviewed (AWS Marketplace shows 0 reviews; PeerSpot indicates 0 collected reviews). Buyers who require extensive peer validation may prefer more widely reviewed platforms. 5. You want a single product to replace SIEM/SOAR/XDR entirely - Query is positioned primarily as a federated search/control plane and data operations layer and may not provide the full range of consolidated detection, storage, and response features of a dedicated SIEM or XDR platform.

Deal disqualifiers (poor fit)

Requirement for deterministic low-latency search over very large historical datasets where APIs are slow
Need for large-scale relevance ranking and unified cross-source scoring (index-centric requirements)
Unwillingness to manage API access, connector health, and permissions complexity

Vendor-acknowledged or documentation-implied limitations

The platform requires specifying a time range to avoid overly large scans; this can limit exploratory searches unless analysts can identify likely timeframes.
Connector availability appears to be evolving; some connectors may require vendor assistance to add, indicating the connector catalog may not be fully self-serve in all cases.

Roadmap signals (not firm commitments)

Vendor blog posts reference planned capabilities (additional plug-ins, collaboration features, workbench enhancements, and more integrations) without public timelines.

Security and compliance gaps or unknowns

SOC 2 is claimed, but the Type (I vs II) and auditor details are not public. ISO certifications are not clearly stated.
Data residency and detailed enterprise controls (SCIM, audit log specifics, RBAC granularity) are not clearly documented publicly.

02Why they buy

Unique selling points supported by vendor materials (stated as vendor claims)

Runtime federated search with OCSF-aligned normalization, described in product documentation.
Splunk app integration intended to extend Splunk searches to external datasets without ingesting those datasets into Splunk indexes.
A security-focused product framing (SecDataOps/control plane) rather than a general enterprise search product.

Claims that require verification

The vendor states specific numerical outcomes (for example, reduced ingestion fees and faster investigations). These outcome claims lack public methodology and independent validation in the sources reviewed and should be validated via reference calls and pilots.

Areas where competitors may have advantages

Broader public adoption and community footprint (e.g., some pipeline and observability vendors)
Index-based performance and relevance tuning for large-scale analytics
Native cohesion with existing platform investments (e.g., Splunk-native capabilities for Splunk-first environments)

03Field reports

Review platform reality check

Independent end-user review content on mainstream review platforms is limited; marketplace and peer-review listings show minimal independent review volume for this product.

Vendor-published testimonials (not independent reviews)

Early vendor materials include customer quotes attributed to recognizable organizations; these function as vendor-selected references. Examples reference a major media company and a large law firm about usage and outcomes. These references may reflect valid customer experiences, but prospective buyers should request: - Named references for live reference calls - Specifics on deployment scope (connectors used, time range searched, data volumes) - Clarification on what functionality was replaced versus augmented (e.g., SIEM, SOAR, data lake)

Community / social proof

No substantive community discussion threads were identified during this research pass. The product name is generic, which may complicate searches; community discussion appears limited based on accessible results.

What customers likely choose Query for (inferred from product claims and problem fit)

Reducing SIEM ingestion costs by leaving data in place, subject to validation during procurement
Minimizing analyst context-switching across multiple tools
Supporting SIEM migration or modernization toward a security lakehouse model (aligned with partnership messaging)

Why some customers might not choose it (inferred)

Preference for indexed search performance and relevance tuning
Low tolerance for API latency or rate limits
Desire for a mature independent review footprint or broader community adoption

Public case studies

No detailed public case study PDFs with quantified methodology were located in the sources reviewed.

Vendor-quoted outcomes (treated as directional claims)

The vendor provides outcome claims on its homepage that include statements such as reduced ingestion fees and faster investigations. These claims are presented without public methodology or sample-size details and therefore should be validated during procurement. Prospective buyers should request: - How metrics (e.g., speedups) were measured (mean/median, workflows used) - The data sources and scope included in measurements - Whether reported savings include labor and pipeline costs - Whether monetary savings are reported per customer or cumulatively across customers

04Best fit

Company sizes

Likely best fit: mid-market to enterprise organizations with mature security teams and multiple major tools.
Less likely fit: very small companies without complex security stacks or meaningful SIEM ingestion costs.

Industries

Likely strongest fit where regulatory retention requirements generate large log volumes and hybrid environments create data fragmentation.
Early references include media and legal organizations, though these are not comprehensive.

Roles/personas

Decision makers: CISO, VP SecOps, Head of SOC, Director of Security Engineering
Champions/users: incident responders, threat hunters, detection engineers, security data engineers

Qualification criteria (good fit)

Multiple security data sources and frequent investigations requiring cross-tool correlation
Significant SIEM ingestion costs or pressure to reduce data duplication
Interest in OCSF or a normalized security data model
Need to access both real-time and archived data without rehydrating into a SIEM

05The pitch

What the product does (objective value proposition)

Query (often referenced as “Query.AI” in older press) is a federated search and security data operations (SecDataOps) platform designed to let security teams query security-relevant data where it already resides (SaaS tools, SIEMs, data lakes, warehouses, cloud storage, etc.) rather than ingesting or duplicating all data into a single system. The product documentation describes normalization of results to an OCSF-based model and enrichment to support investigations, hunting, and incident response. Key product themes across vendor materials: - Federated search across many tools using API-based connectors, returning normalized results (OCSF/QDM). - Splunk integration: a Splunk app that extends Splunk searches to external sources without additional Splunk ingestion costs. - “Security Data Mesh” positioning: connecting distributed security data rather than centralizing it. - AI Agents described for triage, contextualization, enrichment, and response workflows. - Security data pipelines referenced in marketplace positioning (e.g., Parquet/ZSTD and no-YAML messaging), though details and maturity are not fully documented publicly.

Target market and market positioning

Primary buyers/users: enterprise or mid-market SOC / SecOps teams, incident responders, detection engineers, and security leadership seeking to reduce SIEM ingestion costs and tool-switching overhead.
Positioning: described as a control plane/data mesh/federated search for security, framed as an approach to reduce vendor lock-in and the cost or effort of centralization.

Get a comprehensive analysis of Query including market position, competitive landscape, adoption trends, and peer benchmarks.

Download full report →