AkasicDB: Demonstrating Omni RAG with a Unified Vector-Graph-Relational DBMS

AkasicDB is a database system that natively supports Omni RAG, a Retrieval-Augmented Generation (RAG) formulation that jointly accesses vector, graph, and relational data within a single execution framework. The paper states: 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. It extends the authors' prior work, Chimera, with native vector support to enable such unified execution, and demonstrates the first native integration of Vector–Graph–Relational RAG, which we refer to as Omni RAG.

The motivation is that existing RAG systems combine vector retrieval with either graph traversal (Graph RAG) or relational filtering (Filtered vector search), but no single workflow has demonstrated the joint integration of all three. This limitation stems from the absence of a suitable database system architecture that can natively integrate these retrieval modalities within one execution framework. Existing approaches rely on either out-of-DB integration of native systems (e.g., Neo4j, Milvus) or in-DB non-native integration (e.g., PostgreSQL with Apache AGE and pgvector), both of which suffer from high overhead. Out-of-DB integration requires multi-turn retrieval across systems, producing excessive intermediate data, leading to redundant data transfer, increased latency, and inefficient resource utilization. In-DB non-native integration translates graph traversal into relational joins and stores vectors as generic arrays, causing substantial overhead and lacking graph- and vector-specific optimization.

AkasicDB's architecture consists of (i) dedicated storage components for vector, graph, and relational data, and (ii) a unified query processing layer that coordinates traversal, join, and similarity search within the same execution framework. It extends Chimera's dual-store design into a triple-store design with a native vector store, graph store (adjacency-list), and relational store (PostgreSQL tables), all sharing a common transaction manager. Indexing includes B-tree indexes for graph and relational stores, and HNSW, IVF, and Vamana for vector similarity search. For query processing, AkasicDB extends Chimera's Traversal-Join (TJ) operator by integrating vector similarity search following the VBASE design, exposing ANN index traversal as an iterator-based operator with an Open/Next/Close interface, enabling all operations to be composed within a single Volcano-style execution plan with global top-k semantics enforced by ORDER BY and LIMIT.

The demonstration is interactive and chat-style, with six steps: (1) configuration (selecting RAG mode and target system), (2) data source selection (e.g., Agriculture, Computer Science, Legal, Mixed), (3) model selection (LLM for generation), (4) input question, (5) LLM response, and (6) retrieval statistics and inspection, including graph view (Cytoscape layout), relational view (tabular layout), and chunk view (document-style layout). Two scenarios are presented: Scenario 1 compares answer quality between Vector RAG and Omni RAG using both human voting and LLM-as-a-judge; Scenario 2 compares system efficiency across different backend architectures by varying selectivity.

Experiments were conducted on four datasets from the UltraDomain benchmark (Agriculture, CS, Legal, Mix). For answer quality, Omni RAG consistently outperforms Vector RAG by 4–28 percentage points, with the largest gain on Mix. For system efficiency, under a 20% selectivity setting, AkasicDB achieves the lowest retrieval time across all datasets, reducing latency by orders of magnitude compared to PGVector+AGE and by 2–9× compared to Neo4j and Milvus configuration. Generation time is dominated by LLM inference, but retrieval time can become a primary bottleneck under complex Omni RAG settings. The paper concludes that AkasicDB highlights the practical benefits of unified vector-graph-relational processing for emerging RAG workloads.

Improvements to AI Systems:

1. Unified Multi-Modal Retrieval Engine – Replace fragmented pipelines (separate vector DB, graph DB, relational DB) with a single execution framework that natively fuses vector similarity, graph traversal, and relational filtering in one query plan. This eliminates redundant data transfer and intermediate materialization, reducing retrieval latency by orders of magnitude under selective filters.

2. Iterator-Based ANN Integration – Expose approximate nearest neighbor (ANN) search (HNSW, IVF, Vamana) as a first-class iterator operator (Open/Next/Close) within a Volcano-style execution plan. This allows the AI system to compose ANN with joins and traversals without custom glue code, enabling global top-k semantics (ORDER BY + LIMIT) across heterogeneous data types.

3. Cross-Modal Query Optimization – Implement a cost-based optimizer that decides the optimal order of vector search, graph hops, and relational predicates (e.g., push selectivity early). This reduces the search space and avoids scanning irrelevant vectors or nodes, improving efficiency under low-selectivity conditions (e.g., 20% selectivity yields 2–9× speedup over Neo4j+Milvus).

4. Unified Transactional Consistency for RAG – Use a shared transaction manager across vector, graph, and relational stores, ensuring that retrieval reads are consistent with recent updates. This prevents stale or inconsistent context during generation, critical for real-time RAG over frequently updated knowledge bases.

5. Adaptive Retrieval Strategy Selection – Based on query complexity and data distribution, the system can dynamically choose between Vector RAG, Graph RAG, Filtered Vector Search, or Omni RAG. This is enabled by the unified architecture, allowing the AI to trade off answer quality (4–28% improvement with Omni RAG) versus latency based on user needs or resource constraints.

6. Explainable Retrieval Statistics – Provide per-query breakdowns (e.g., number of vectors scanned, graph hops, relational rows filtered) as structured output. This allows the AI system to self-monitor and tune retrieval parameters (e.g., HNSW ef, traversal depth) or trigger fallback strategies when retrieval quality degrades.

7. Multi-Domain Generalization – Leverage the unified store to handle mixed-domain queries (e.g., Agriculture + Legal) without manual schema integration. The system can join entities across domains via graph edges and relational keys, improving answer accuracy on heterogeneous datasets (largest gain on Mix dataset).

---

What the Improved AI System Can Do:

• Answer complex questions requiring simultaneous reasoning over unstructured text (vectors), entity relationships (graph), and structured attributes (relational) in a single pass, with 4–28% higher answer quality than vector-only RAG.

• Execute such queries with sub-second retrieval latency even on large datasets, by avoiding multi-system round-trips and using native vector–graph–relational co-optimization.

• Dynamically switch between retrieval modes (vector-only, graph-only, filtered, or Omni) based on query type and latency budget, without code changes.

• Provide transparent, inspectable retrieval traces (chunks, graph paths, relational rows) for debugging and human-in-the-loop validation.

• Scale to new domains by ingesting heterogeneous data into the triple-store, with automatic indexing and query planning across all three modalities.