TigerVector: Supporting Vector Search in Graph Databases for Advanced RAGs

This paper introduces TigerVector, a system integrated into TigerGraph v4.2 that unifies vector search and graph querying through an MPP index framework and enhanced GSQL language, demonstrating superior hybrid search performance and scalability compared to leading graph and vector databases.

The Gist

Imagine you are trying to find the perfect book recommendation for a friend.

The Old Way (Vector Databases):
You have a giant library where every book is described by a "vibe" (a mathematical vector). You ask the librarian, "Give me books with a 'cozy mystery' vibe." The librarian scans the vibe descriptions and hands you a stack of books.

• The Problem: The librarian doesn't know who wrote the books, where they were published, or if the author is actually your friend's favorite. They only know the "vibe." If you ask for "cozy mysteries by authors who live in Paris," the librarian gets confused because they can't connect the vibe to the author's location.

The Graph Way (Graph Databases):
You have a library where every book is connected by strings to its author, its city, and its genre. You can walk along these strings to find exactly what you need.

• The Problem: If you ask for "cozy mysteries," the librarian has to read every single book cover to figure out the vibe. It's slow.

The New Solution: TigerVector
The paper introduces TigerVector, a system that combines the best of both worlds. It's like building a library where every book has a "vibe tag" and is connected by strings to its author and location. You can ask, "Find me books with a 'cozy mystery' vibe, written by authors living in Paris," and the system does both tasks instantly.

Here is how they did it, using some simple analogies:

1. The "Two-Desk" vs. "One Super-Desk" Problem

Previously, if you wanted to do this, you had two separate desks in the office:

• Desk A (Vector): Handles the "vibes."
• Desk B (Graph): Handles the "connections."
  To get an answer, you'd have to run back and forth between them, copying data from one to the other. This is slow and messy.

TigerVector builds a Super-Desk. It puts the "vibe tags" right next to the "connection strings" on the same piece of paper. Now, the librarian can check the vibe and follow the strings without ever leaving their chair. This saves time and ensures the data is always consistent (you don't have to worry if the "vibe" on Desk A matches the "author" on Desk B).

2. The "Library of Congress" vs. "The Neighborhood" (MPP Architecture)

Imagine you have a library with 100 million books. If one librarian tries to find a book, it takes forever.
TigerGraph (the engine behind TigerVector) is like a massive team of librarians. They split the library into 100 different rooms (segments).

• When you ask a question, the "Head Librarian" (Coordinator) shouts the question to all 100 rooms at once.
• Each room searches its own stack of books simultaneously.
• They all shout their top 10 results back to the Head Librarian, who combines them into one perfect list.
  This is called MPP (Massively Parallel Processing). It's why TigerVector is so fast—it's not one person running a marathon; it's 100 people running a relay race.

3. The "Separate Filing Cabinet" (Decoupled Storage)

Here is a tricky part: "Vibe tags" (vectors) are huge. A single book's vibe might take up as much space as 1,000 pages of text. If you stuffed these huge tags into the regular book catalog, the catalog would become bloated and slow to update.

TigerVector's Trick:
They keep the regular book catalog (the graph) in one cabinet and the giant "vibe tags" in a special, separate filing cabinet right next to it.

• Why? When you update a book's author (graph data), you don't have to touch the giant vibe cabinet.
• Why? When you update a vibe, you don't have to shuffle the whole book catalog.
• The Result: Updates happen instantly without breaking the whole system. It's like having a "Quick Update" drawer for the tags so you don't have to reorganize the whole library every time you change a single detail.

4. The "Smart Filter" (Hybrid Search)

This is the magic sauce for RAG (Retrieval-Augmented Generation), which is how AI chatbots like me find information.

• Scenario: You want to find "Reviews of Italian restaurants in New York that are highly rated."
• The Old Way: The AI might find "Italian restaurants" (Graph) and then guess which ones are "highly rated" (Vector), or vice versa. It often misses the mark.
• TigerVector's Way: It says, "Okay, let's first find all restaurants in New York (Graph filter). Then, within that specific group, let's find the ones that smell like 'highly rated' (Vector search)."
  It filters the crowd before doing the complex vibe check. This makes the answer much more accurate and saves the AI from making up facts.

5. The "Teamwork" (Query Composition)

TigerVector lets you mix and match tools like a chef mixing ingredients.

• You can use a Graph Algorithm (like finding a community of friends) to create a list of candidates.
• Then, you immediately feed that list into a Vector Search to find the most relevant items within that group.
• All in one single sentence (query).
  It's like telling a chef: "Find all the people in the 'Foodie' club, and then pick the three who love spicy food the most." You don't need to ask for the club list, write it down, and then ask a second question. You just ask once.

The Bottom Line

TigerVector is a breakthrough because it stops treating "vibes" (AI data) and "connections" (relationship data) as enemies that need to live in separate buildings. It brings them into the same room, gives them a team of super-fast workers, and lets them work together seamlessly.

The Result?

• Faster: It's significantly faster than existing graph databases (like Neo4j) and even beats specialized vector databases (like Milvus) in some tests.
• Smarter: It allows AI to understand context and relationships much better, leading to fewer hallucinations and better answers.
• Cheaper: Because it's so efficient, you need less expensive hardware to run it.

In short, TigerVector is the bridge that finally lets AI understand not just what things are, but how they are connected to everything else.

Technical Summary

Here is a detailed technical summary of the paper "TigerVector: Supporting Vector Search in Graph Databases for Advanced RAGs."

1. Problem Statement

The paper addresses the limitations of current Retrieval-Augmented Generation (RAG) systems.

• Vector-Only RAG Limitations: Traditional RAGs rely on vector databases (e.g., Milvus) to store semantic embeddings. While effective for semantic similarity, they fail to capture complex structural relationships between data objects, leading to poor prompt hit rates and the need for costly, iterative LLM API calls.
• GraphRAG Limitations: GraphRAG uses graph databases (e.g., Neo4j) to model relationships but often lacks efficient native vector search capabilities.
• Current Hybrid Solutions: The straightforward approach of using separate vector and graph databases creates data silos, increases data movement, complicates data consistency (atomic updates), and requires managing access controls across two systems.
• Existing Graph Database Gaps: While some graph databases (Neo4j, Amazon Neptune) have added rudimentary vector search, they suffer from:
  • Lack of high performance compared to specialized vector DBs.
  • Inability to support advanced queries (filtered vector search, hybrid graph-vector search).
  • Non-atomic updates and lack of support for multiple embedding types.
  • Poor scalability (e.g., single global index in Neptune).

2. Methodology: TigerVector System Design

The authors propose TigerVector, a system integrated natively into TigerGraph (a Massively Parallel Processing, MPP, native graph database) to unify vector and graph search.

A. Core Architecture & Storage

• Decoupled Storage: Unlike traditional approaches where vectors are stored as simple lists within nodes, TigerVector separates vector embeddings from other graph attributes.
  • Embedding Segments: Vectors associated with a specific vertex segment are stored in a separate "embedding segment."
  • Indexing: A vector index (HNSW) is built per embedding segment. This allows local search on each node, minimizing network overhead during distributed queries.
• MPP Integration: The system leverages TigerGraph's MPP architecture. Queries are distributed across segments; each server performs a local top-$k$ search, and results are merged globally. This ensures linear scalability.
• Embedding Type & Space:
  • Introduces a new EMBEDDING data type to manage metadata (dimension, model, metric) explicitly, rather than treating vectors as generic LIST<FLOAT>.
  • Supports Embedding Spaces, allowing multiple vertex types to share a unified schema for embeddings generated by the same model.

B. Transactional Consistency & Updates

• MVCC for Vectors: TigerVector employs Multi-Version Concurrency Control (MVCC) for vector updates.
• Delta Store: Updates (inserts/deletes) are accumulated in an in-memory delta store.
• Two-Stage Vacuum:
  1. Delta Merge: Flushes deltas to disk files.
  2. Index Merge: Incrementally merges delta files into the HNSW index snapshot.
• Atomicity: Updates involving both graph attributes and vector attributes are performed atomically, ensuring consistency without blocking other queries.

C. Query Language (GSQL) Integration

TigerVector extends the GSQL query language to support declarative vector search:

• Basic Syntax: Extends ORDER BY ... LIMIT with VECTOR_DIST for similarity ranking.
• Filtered Vector Search: Uses a pre-filter approach. The graph engine filters vertices based on attributes (generating a bitmap), which is then passed to the vector index. This is more efficient than post-filtering for low-selectivity filters.
• Vector Search on Graph Patterns: Supports hybrid queries where vector search is performed on a vertex set filtered by complex graph traversals (e.g., "Find top-k posts by friends of Alice").
• Vector Similarity Join: Enables finding top-$k$ similar pairs of nodes connected by a specific graph pattern (e.g., finding similar patient journeys).
• VectorSearch() Function: A procedural function that accepts vertex sets as input (filters) and returns vertex sets, enabling complex query composition with graph algorithms (e.g., Community Detection + Vector Search).

3. Key Contributions

1. Unified System: A native integration of vector search into a distributed graph database, eliminating data silos and ensuring ACID consistency between graph and vector data.
2. MPP Vector Indexing: A novel design where vector indexes are built per vertex segment, enabling horizontal scaling and efficient distributed search without the network overhead of cross-segment index traversal.
3. Advanced Query Capabilities: Full support for filtered vector search, hybrid graph-vector queries, and vector similarity joins within a single declarative language (GSQL).
4. Efficient Updates: A transactional, incremental update mechanism for vector indexes that does not degrade graph performance.
5. New Data Types: Introduction of the EMBEDDING type and EMBEDDING SPACE concepts to manage metadata and multiple embedding models efficiently.

4. Experimental Results

The authors evaluated TigerVector against Neo4j, Amazon Neptune, and Milvus (a specialized vector DB) using SIFT100M/1B and Deep100M/1B datasets.

• Performance vs. Graph DBs:
  • Throughput: TigerVector achieved 3.77× to 5.19× higher throughput than Neo4j.
  • Recall: Achieved 23% to 26% higher recall than Neo4j at the same throughput.
  • Cost Efficiency: Compared to Amazon Neptune, TigerVector achieved 1.93× to 2.7× higher throughput on hardware that was 22.42× cheaper (using standard cloud instances vs. Neptune's massive memory units).
• Performance vs. Specialized Vector DB (Milvus):
  • TigerVector achieved comparable or higher throughput (1.07× to 1.61×) than Milvus, attributed to C++ implementation and effective MPP parallelism.
  • Latency was slightly lower (up to 1.16× faster) than Milvus.
• Scalability:
  • Showed near-linear scalability when doubling the number of nodes (1.84× to 1.91× throughput gain).
  • Maintained performance stability when scaling dataset size from 100M to 1B vectors.
• Update Performance:
  • Index building was 5.2× to 6.8× faster than Neo4j and 1.86× to 2.16× faster than Milvus.
  • Incremental updates were efficient, with a threshold identified where rebuilding the index is more efficient than incremental updates if >20% of vectors change.
• Hybrid Search: Successfully demonstrated complex hybrid queries (e.g., LDBC-SNB benchmarks) where vector search time remained in milliseconds even with millions of candidate nodes.

5. Significance

• Enabling Advanced RAGs: TigerVector provides the infrastructure for VectorGraphRAG, allowing LLMs to ground responses in both semantic similarity (vectors) and structural context (graphs) simultaneously.
• Operational Efficiency: By unifying vector and graph data, organizations can reduce data engineering complexity, ensure data consistency, and simplify access control governance.
• Industry Impact: Integrated into TigerGraph v4.2 (released Dec 2024), it sets a new standard for graph databases, proving that native vector search can match or exceed the performance of specialized vector databases while offering superior graph capabilities.
• Generalizability: The design principles (decoupled storage, segment-level indexing, MPP integration) are applicable to other graph database systems, suggesting a path forward for the broader industry.