Source-linked AI summary
AkasicDB: Demonstrating Omni RAG with a Unified Vector-Graph-Relational DBMS
Geonho Lee, Jeongho Park, Donghyoung Han, Min-Soo Kim
TL;DR
Existing architectures make it difficult to execute vector, graph, and relational retrieval together efficiently. AkasicDB natively combines these modalities in one execution framework, and its Omni RAG demonstration reports better answers than Vector RAG alongside lower retrieval latency than alternative configurations.
Problem
Existing RAG workflows combine vector retrieval with either graph traversal or relational filtering, while joint integration of all three modalities lacks suitable native database support.
Source: §1 · p. 1Method
AkasicDB extends Chimera with native vector support and integrates vector similarity, graph traversal, and relational filtering in one execution framework for Omni RAG.
Source: §1 · p. 1, §2 · p. 2, §3.3 · p. 3Results
Omni RAG outperforms Vector RAG by 4–28 percentage points, and AkasicDB achieves the lowest retrieval time across datasets, reducing latency by 2–9× compared to the Neo4j and Milvus configuration.
Source: §5 · p. 4Takeaways & Limitations
Interactive scenarios let users compare Vector RAG and Omni RAG answer quality and observe performance differences across systems, illustrating the practical benefits of unified processing.
Source: §6 · p. 4Extension-based in-DB systems can express Omni RAG queries but still execute inefficiently because graph and vector operations remain non-native to the core engine.
Source: §3.1 · p. 2
Abstract
from arXiv · showhide
Recent Retrieval-Augmented Generation (RAG) systems increasingly combine vector retrieval with structured knowledge, such as Graph RAG and Filtered vector search. However, existing database architectures struggle to support such complex RAG workflows efficiently, as they rely on out-of-DB pipelines or in-DB non-native integration, leading to high overhead. This demo paper presents AkasicDB, a database system that natively supports such RAG workflows by jointly executing vector similarity search, graph traversal, and relational filtering within a single execution framework. AkasicDB extends our prior work, Chimera, with native vector support to enable such unified execution. Based on AkasicDB, we demonstrate the first native integration of Vector-Graph-Relational RAG, which we refer to as Omni RAG. Through an interactive chat-style demonstration, users execute and visualize Omni RAG queries, directly experiencing its superior retrieval and reasoning over vector-only approaches while observing the practical limitations of existing database architectures in supporting Omni RAG. A demonstration video is available at https://youtu.be/8d09_dtrEIM
1 Introduction
RAG has expanded from vector-centric retrieval to graph and relational techniques, but no single workflow had jointly integrated all three modalities. AkasicDB addresses this gap by extending Chimera with native vector support and demonstrating Omni RAG.
1 Introduction
- Existing Graph RAG and Filtered vector search approaches evolved largely in isolation, leaving no demonstrated workflow jointly integrating vector, graph, and relational retrieval.Combining the modalities typically required out-of-DB orchestration or non-native in-DB extensions, hindering unified execution, visualization, and interaction.Source: §1 · p. 1
- AkasicDB extends Chimera with native vector support so vector similarity, graph traversal, and relational filtering run within one execution framework.Chimera introduced unified query processing for graph and relational data.Source: §1 · p. 1
- The demonstration presents the first native Vector–Graph–Relational RAG integration, Omni RAG, and lets users compare its retrieval and reasoning with vector-only approaches.It also contrasts Omni RAG with out-of-DB native systems and in-DB non-native extensions.Source: §1 · p. 1
2 Omni RAG
Omni RAG jointly accesses vector, graph, and relational data, specifying what to retrieve from each modality. It combines similarity search over text, traversal of entity relationships, and filtering over structured attributes.
2 Omni RAG
- Graph RAG expands retrieved context through entity relationships, whereas filtered vector search excludes irrelevant content to improve precision.Vector RAG retrieves semantically similar text chunks using question and document embeddings.Source: §2 · pp. 1–2
- Omni RAG jointly accesses vector, graph, and relational data and explicitly specifies what to retrieve from each modality.Its retrieval combines vector similarity over unstructured text, graph traversal over entity relationships, and relational filtering over structured attributes.Source: §2 · p. 2
3 AkasicDB System Overview
AkasicDB addresses Omni RAG's architectural demands with in-DB native integration and unified processing across vector, graph, and relational data. Its design combines dedicated stores with query operators that compose all three modalities.
3.1 System Design for Omni RAG
- Multi-system Omni RAG retrieval materializes and transfers excess intermediate results before a final top-k restriction, increasing latency and resource use.Graph or relational selectivity is unknown in advance, making it difficult to determine how many results each system should produce.Source: §3.1 · p. 2
- AkasicDB uses native in-DB integration, coordinating traversal, joins, and similarity search through dedicated stores and a unified query-processing layer.Extension-based systems can express Omni RAG in one query but remain inefficient because graph traversal becomes relational joins, vectors use generic arrays, and planning lacks modality awareness.Source: §3.1 · p. 2
3.2 Vector-Graph-Relational Storage
- AkasicDB extends Chimera's graph and relational stores with a native vector store, co-located under a shared transaction manager for consistent access.Vectors use disk-based segments; the stores support B-tree indexes, while vector search supports HNSW, IVF, and Vamana approximate-neighbor indexes.Source: §3.2 · pp. 2–3
3.3 Unified Query Processing
- AkasicDB extends Chimera's Traversal-Join operator with iterator-based ANN search, composing vector, graph, and relational operations in one execution plan.Upstream ORDER BY and LIMIT operators enforce global top-k semantics.Source: §3.3 · p. 3
4 Demonstration Scenarios
The demonstration guides users through configuring and running Omni RAG, inspecting retrieved evidence, and comparing answer quality and system efficiency. Users can compare response quality against Vector RAG and observe retrieval and generation times across system configurations.
4.1 End-to-End Experience
- Users configure a RAG mode and system, select a domain and language model, enter a question, then inspect the response and modality-specific retrieval statistics.The interface reports retrieval and generation time separately and provides graph, relational, and text-chunk views.Source: §4.1 · pp. 3–4
4.2 Scenario 1 – Answer Quality Comparison
- For the same question and data source, users compare Vector RAG and Omni RAG answers side by side and vote on which response is better.An LLM-as-a-judge assessment is also shown alongside human preferences.Source: §4.2 · p. 4
4.3 Scenario 2 – System Efficiency Comparison
- Users vary the backend and date range, then compare retrieval and generation times to observe how system architectures affect chat responsiveness.The same question can be issued under different configurations.Source: §4.3 · p. 4
5 Experiments
Experiments compare Omni RAG answer quality and latency across four UltraDomain-derived datasets and system configurations. Omni RAG improves answer quality, while AkasicDB achieves the lowest retrieval time.
5 Experiments
- Evaluation spans four UltraDomain datasets and compares AkasicDB with PostgreSQL extensions, Neo4j+Milvus, and Neo4j Vector.The datasets are Agriculture, CS, Legal, and Mix.Source: §5 · p. 4
- Omni RAG beats Vector RAG by 4–28 percentage points in winning ratio across datasets, with the largest gain on Mix.Table 1 reports answer quality in its upper part.Source: Table 1 · p. 4, §5 · p. 4
- At 20% selectivity, AkasicDB has the lowest retrieval time: orders-of-magnitude lower than PGVector+AGE and 2–9× lower than Neo4j+Milvus.Latency is measured as time-to-first-token, including retrieval and generation time.Source: §5 · p. 4, Table 1 · p. 4
6 Conclusions
The conclusion presents AkasicDB as a single-system DBMS for Omni RAG and reports an interactive comparison of retrieval approaches and systems. It highlights unified vector-graph-relational processing as practically beneficial for emerging RAG workloads.
6 Conclusions
- AkasicDB is presented as a vector-graph-relational DBMS for efficient Omni RAG within one system.The demonstration presents it as addressing difficulties that existing architectures face in realizing Omni RAG.Source: §6 · p. 4
- Interactive scenarios let users compare Vector RAG and Omni RAG response quality and performance across systems.Users can directly experience the performance differences.Source: §6 · p. 4
- The conclusion highlights practical benefits of unified vector-graph-relational processing for emerging RAG workloads.Source: §6 · p. 4