For decades, data analysis has been built around two fundamental analytical needs: search and analytics.
When teams needed to locate specific documents, logs, or records, they relied on search engines such as Elasticsearch, optimized for fast retrieval and relevance ranking. When they needed to process billions of rows for reporting, trend analysis, or complex joins, they turned to OLAP databases such as Apache Doris, designed for large-scale aggregation and analytical workloads.
This separation worked well — as long as search and analytics were used independently. But what happens when applications need to do both, at the same time, on the same data, and in real time?
Consider AI observability. To understand how users react to LLM responses, teams need to analyze trends and feedback scores for specific topics embedded in generated text. This requires full-text and vector search to retrieve relevant responses, followed by time-based aggregation and statistical analysis to measure how sentiment or feedback evolves over time.
Or consider customer-facing analytics in SaaS applications. Modern SaaS CRM systems allow customers to search user profiles using free text, then correlate the matched users with behavioral events to understand usage patterns, conversion funnels, or churn signals. These workflows require searching user profiles, joining with event data, and aggregating across large datasets — all within an interactive experience.
The same pattern appears in Generative AI applications. A question like “What is the sales forecast for AI-related products next quarter?” involves multiple steps: first, retrieving relevant products using full-text and vector search, then, joining product metadata with historical sales data, and aggregating the results to produce compact, high-quality context for an LLM — reducing both latency and token usage.
These hybrid search-and-analytics workloads are no longer edge cases. They are becoming increasingly common in the era of Generative AI, where unstructured data plays a central role and interactive, efficient search is more important for unstructured data such as text and embeddings.
Yet today, most systems still attempt to solve this problem by gluing search engines and OLAP databases together. This approach leads to duplicated data pipelines, inconsistent results, operational complexity, and unnecessary latency — especially when freshness and interactivity matter.
It is time for a new database paradigm. Hybrid Search and Analytical Processing (HSAP) is designed to execute search and analytics together, in one system, over one copy of data, with a unified execution engine.
1. The Pain of Splitting Search and Analytics
In many real-world architectures today, search and analytics are handled by different systems — for example, Elasticsearch for search and an OLAP database such as Apache Doris or ClickHouse for analytics. While this approach is common, it comes with high costs (and is often underestimated).
- Development and operational complexity: Maintaining multiple systems means multiple ingestion pipelines, schemas, APIs, query languages, and operational playbooks. Over time, the complexity of coordinating these systems becomes a bottleneck for development velocity and reliability.
- Duplicated storage and ingestion cost: Data must be ingested and stored twice. This duplication doubles infrastructure cost and makes schema evolution and backfills significantly more expensive.
- Inconsistent data and delayed insights: Data inconsistency is a more critical problem than cost. As a result, different parts of the application get different versions of data, leading to delayed or inconsistent insights and final bad user experience.
- Inability to combine search and analytics in a single query: When search and analytics live in separate systems, it becomes expensive and even impossible to express queries that naturally combine both. Teams are forced to decompose a single logical question into multiple steps: search first, then analyze — often across different systems and query languages.
These problems are not accidental. They are the direct result of splitting search and analytics across systems.
2. What Is Hybrid Search and Analytical Processing: A New Database Paradigm
Hybrid Search and Analytical Processing (HSAP) is a database model designed to natively support both search and analytical workloads within a single system.
Search workloads include structured filters, full-text search, and vector search. Analytical workloads include aggregation, sorting, joins, and more complex queries.
HSAP is not about adding analytical features to a search engine, nor about bolting search capabilities onto an OLAP database. Instead, it treats search and analytics as first-class citizens, executed together by a unified engine over the same data.
At its core, HSAP represents a shift from separate systems and pipelines to a single execution model for hybrid queries.
3. Why Hybrid Search and Analytical Processing Matters in Practice
Hybrid Search and Analytical Processing (HSAP) matters because it fundamentally simplifies how applications query, manage, and operate data.
One system, one execution engine for search and analytics
HSAP enables hybrid queries that combine search filters, aggregations, sorting and joins within a single query and execution plan.
This is not "analytics on search data" OR "search bolted onto OLAP". Instead, search and analytics are planned, optimized, and executed together by the same engine.
One system, one copy of data
With HSAP, data is stored once and queried consistently. There is no duplicated storage, no ingestion fan-out and no inconsistency or synchronization lag.
This guarantees strong consistency between search results and analytical insights.
One system, one API interface
HSAP exposes a unified query interface — typically SQL — eliminating the need to bridge multiple query languages and APIs across systems. It makes data application development more easy and productive.
One system, one operational model
By consolidating search and analytics into a single system, teams reduce operational overhead. It means fewer systems to deploy and monitor and lower total cost of ownership.
HSAP simplifies not only query execution, but also data management, APIs, and operations.
4. Why Hybrid Search and Analytical Processing Matters More in the GenAI Era
While Hybrid Search and Analytical Processing (HSAP) is valuable on its own, its importance is amplified in the era of Generative AI.
Search explodes in GenAI applications
GenAI applications rely heavily on search — from full-text search to vector and hybrid search. Search is no longer just about retrieval; it is about context selection for reasoning and generation.
AI agents need both memory and reasoning
AI agents continuously interact with data. In this process, search serves as memory and analytics provides insights and reasoning.
These two capabilities are inseparable in real AI workflows, making hybrid queries the norm rather than the exception.
A strong signal from Rockset and OpenAI
Rockset demonstrated that HSAP is foundational for AI systems by building a unified architecture on top of RocksDB. The importance of this category was validated when OpenAI acquired Rockset. OpenAI didn't buy a vector database; they bought a real-time search and analytics engine. They recognized that AI data infrastructure requires the ability to search and analyze data in real-time.
At the same time, it left a gap in the open market — creating an opportunity for a new generation of HSAP databases.
5. VeloDB: A Production-Ready Real-Time HSAP Database
VeloDB is designed from the ground up as a real-time analytics database where search is a first-class capability.
In VeloDB, search and analytics are not treated as separate subsystems. Instead, they are executed by the same columnar storage layer and a distributed, vectorized execution engine. To support hybrid workloads, VeloDB provides a rich set of built-in indexes, including primary index, zonemap index, Bloom filter index, inverted index, and vector index. These indexes enable efficient execution of a wide spectrum of search patterns, ranging from structured filtering to full-text and vector-based semantic search.
At the same time, VeloDB implements a high-performance columnar storage format and a massively parallel, vectorized execution engine. This allows VeloDB to efficiently process single-table aggregations, multi-table joins, hybrid search queries, and semi-structured JSON analytics at scale. An intelligent query planner optimizes search and analytical operators together, producing a single, unified execution plan.
As a result, workloads that traditionally require multiple systems can be expressed naturally and executed efficiently in VeloDB.
The examples below show how VeloDB can process queries that need both search and analytics in various use cases:
A. AI Observability:
Analyze the trend and user feedback for the matched LLM logs
SELECT
DATE_TRUNC(ts, 'hour') AS hour,
COUNT() AS num_logs,
AVG(score) AS avg_score
FROM llm_logs
WHERE
ts BETWEEN t1 AND t2
AND llm_response MATCH 'keyword'
B. Customer-Facing Analytics
search and user behavior analysis on a CRM SaaS platform
WITH matched_users AS (
SELECT tenant_id, user_id
FROM user_profiles
WHERE
tenant_id = 'your_tenant_id'
AND region = 'NA'
AND comment MATCH 'keyword'
)
SELECT
e.event_name,
COUNT(*) AS event_cnt,
COUNT(DISTINCT e.user_id) AS user_cnt,
COUNT(*) / NULLIF(COUNT(DISTINCT e.user_id), 0) AS events_per_user
FROM user_events e
JOIN matched_users u
ON e.tenant_id = u.tenant_id AND e.user_id = u.user_id
WHERE
e.event_time >= NOW() - INTERVAL 30 DAY
AND e.event_name IN ('signup','activate','create_invoice','pay_invoice')
GROUP BY e.event_name
ORDER BY event_cnt DESC
LIMIT 30;
C. Generative AI Applications
Hybrid retrieval and analytical context construction for sales forecasts of related products.
WITH product_list AS ( -- hybrid search in products table
SELECT
product_id,
name,
l2_distance(product_vec, :query_embedding) AS dist
FROM products
WHERE
AND is_active = TRUE
AND description MATCH 'AI' -- full-text search
ORDER BY dist ASC LIMIT 200 -- vector search
),
q_sales AS ( -- join with sales table
SELECT
s.product_id,
DATE_TRUNC('quarter', s.sale_date) AS qtr,
SUM(s.revenue) AS qtr_revenue
FROM product_sales s
JOIN product_list p
ON s.product_id = p.product_id
WHERE s.sale_date >= DATE_SUB(CURDATE(), INTERVAL 15 MONTH)
GROUP s.product_id, qtr
)
SELECT -- analyze using aggregation and window functions to construct context
product_id,
AVG(qtr_revenue) AS avg_last4_qtr_revenue,
MAX_BY(qtr_revenue, qtr) AS last_qtr_revenue
FROM (
SELECT
*,
ROW_NUMBER() OVER (PARTITION BY product_id ORDER BY qtr DESC) AS rn
FROM q_sales
) t
WHERE rn <= 4
GROUP BY product_id;
Conclusion
Hybrid Search and Analytical Processing is not just about performance or system consolidation. It represents a shift in how modern applications, especially AI systems, interact with data.
As AI becomes more interactive, real-time, and user-facing, databases must evolve to support hybrid search and analytical workloads natively. HSAP defines this new foundation, and real-time HSAP systems like VeloDB are making it practical at scale.
