GraphRAG with ArcadeDB

Building the Knowledge Graph

Every Graph RAG system starts with knowledge graph construction. The pipeline: chunk your documents, generate embeddings via an LLM, extract entities and relationships, and store everything in the database. Neo4j, Memgraph, and ArangoDB all offer this, but each requires separate systems for vectors, full-text, or documents.

With ArcadeDB, the entire knowledge model (document chunks with embeddings, entity vertices, relationship edges, and full-text indexes) lives in a single transactional database. New documents are searchable across all models immediately. No batch reindexing, no sync pipelines.

• Document chunks with vector embeddings indexed via JVector
• Entity vertices (Person, Concept, Organization) with typed relationships
• MENTIONS edges linking chunks to the entities they reference
• Full-text indexes on entity names and chunk content
• Timestamps on every record for temporal-aware retrieval

Multi-Hop Reasoning: Following the Chain

The most valuable questions require connecting information across multiple documents. "Which researchers at Stanford have published papers on the technique used by the company that acquired our competitor?" requires traversing 4+ hops through the knowledge graph. Vector search alone cannot answer this.

ArcadeDB's graph engine makes multi-hop reasoning a first-class operation. Each hop takes constant time regardless of database size: O(1) per hop. A 5-hop traversal across 10 million entities completes in milliseconds: see the LDBC and LSQB benchmark results for measured numbers against Neo4j, Kuzu, Memgraph, and others.

• Entity-bridge retrieval: Find documents connected through shared entities even when they have low vector similarity
• Community detection: Discover clusters of related entities for global summarization
• Path explanation: Return the exact traversal path so the LLM can explain how information is connected
• Depth control: Adjust traversal depth per query: shallow for speed, deep for thoroughness

Temporal Context: When Facts Change

Knowledge isn't static. Policies get updated, products evolve, organizational structures change, research is superseded. A RAG system that can't distinguish current from outdated information will confidently present stale facts as truth.

ArcadeDB's native time-series capabilities add a temporal dimension that no other Graph RAG platform offers:

• Recency filtering: Retrieve only chunks indexed after a specific date
• Version tracking: Both old and new versions stored: the LLM can see how information changed
• Chunk ordering: Track chunk sequences within documents for contextual retrieval
• Freshness scoring: Weight more recent chunks higher in retrieval ranking
• Change detection: Alert when entity relationships change significantly

For enterprise RAG dealing with compliance documents, product specs, or policy manuals, temporal awareness isn't a nice-to-have: it's essential for avoiding costly mistakes.

Graph RAG Applications

Production Success Story

Does ArcadeDB Have Built-In Vector Search?

Yes. Vector search is native to the engine, not a plugin or a companion service. You store embeddings in a property, create an HNSW index over that property, and query it with the vector.neighbors() function in SQL. Because the index lives in the same database as your graph, a retrieval query can rank chunks by embedding similarity and traverse to the entities they mention without leaving the engine or crossing a network boundary.

Three statements are all it takes: declare the property, index it, and query it.

-- 1. A property to hold the embedding
CREATE PROPERTY Chunk.embedding LIST OF FLOAT;

-- 2. An HNSW index over it
CREATE INDEX ON Chunk (embedding) LSM_VECTOR
  METADATA { dimensions: 1536, similarity: 'COSINE' };

-- 3. Nearest-neighbour search
SELECT content, distance FROM (
  SELECT expand(vector.neighbors('Chunk[embedding]', ?, 5))
);

COSINE is the default similarity metric; EUCLIDEAN and DOT_PRODUCT are also supported. An optional fourth argument to vector.neighbors() sets efSearch, trading recall against latency.

GraphRAG in Python: An End-to-End Walkthrough

This is a complete GraphRAG pipeline running in-process, with no server to start. The arcadedb-embedded package bundles a Java runtime, so pip install is the only prerequisite. Bring your own embedding model; the example below assumes a function embed(text) returning a 1536-dimension list of floats.

pip install arcadedb-embedded

import arcadedb_embedded as arcadedb

DIM = 1536  # must match your embedding model

with arcadedb.create_database("./graphrag") as db:

    # ---- 1. Schema: chunks, entities, and the edge between them ----
    with db.transaction():
        db.command("sql", "CREATE VERTEX TYPE Chunk")
        db.command("sql", "CREATE PROPERTY Chunk.content STRING")
        db.command("sql", "CREATE PROPERTY Chunk.embedding LIST OF FLOAT")
        db.command("sql", "CREATE VERTEX TYPE Entity")
        db.command("sql", "CREATE PROPERTY Entity.name STRING")
        db.command("sql", "CREATE EDGE TYPE MENTIONS")

        # HNSW index over the embedding property
        db.command("sql",
            f"CREATE INDEX ON Chunk (embedding) LSM_VECTOR "
            f"METADATA {{ dimensions: {DIM}, similarity: 'COSINE' }}")

    # ---- 2. Ingest: a chunk, its embedding, and the entities it mentions ----
    docs = [
        ("ArcadeDB stores graph and vector data in one engine.", ["ArcadeDB"]),
        ("JVector provides the HNSW index used for similarity search.", ["JVector", "ArcadeDB"]),
    ]

    with db.transaction():
        for text, entities in docs:
            db.command("sql",
                "CREATE VERTEX Chunk SET content = ?, embedding = ?",
                text, embed(text))

            for name in entities:
                # UPSERT keeps one vertex per distinct entity
                db.command("sql",
                    "UPDATE Entity SET name = ? UPSERT WHERE name = ?",
                    name, name)
                db.command("sql",
                    "CREATE EDGE MENTIONS "
                    "FROM (SELECT FROM Chunk WHERE content = ?) "
                    "TO (SELECT FROM Entity WHERE name = ?)",
                    text, name)

    # ---- 3. Retrieve: vector similarity, then expand through the graph ----
    q = embed("how does ArcadeDB do similarity search?")

    # 3a. Pure vector search
    for row in db.query("sql",
            "SELECT content, distance FROM ("
            "  SELECT expand(vector.neighbors('Chunk[embedding]', ?, 3))"
            ")", q):
        print(row.get("distance"), row.get("content"))

    # 3b. Hybrid: the same chunks, plus what they connect to
    for row in db.query("sql",
            "SELECT content, distance, out('MENTIONS').name AS entities FROM ("
            "  SELECT expand(vector.neighbors('Chunk[embedding]', ?, 3))"
            ")", q):
        print(row.get("content"), "->", row.get("entities"))

Step 3a is what a vector database gives you. Step 3b is the difference: the same ranked chunks, each carrying the entities it mentions, retrieved in one statement against one copy of the data. Adding a second hop (the other chunks that mention those entities) is another traversal in the same query rather than another round trip to another system.

Prefer a server to an embedded process? The same SQL runs unchanged over the HTTP/JSON API or any supported wire protocol, and the official LangChain integration exposes ArcadeDB as a LangChain GraphStore if you would rather drive it from an existing chain.

How Fast Is Retrieval?

Retrieval speed is what decides whether a GraphRAG pipeline can expand context at request time or has to precompute it. On the LDBC Graphalytics suite, run on identical hardware against seven other graph engines, ArcadeDB completes PageRank in 0.10s, WCC in 0.08s, CDLP in 1.11s, and LCC in 2.35s, winning 5 of the 6 standard algorithms. On the LSQB pattern-matching benchmark, query Q6, a two-hop traversal counting 1.67 billion rows, finishes in 110ms, which is 473 times faster than Neo4j on the same host.

Those are traversal numbers, and traversal is the half of GraphRAG that a vector store cannot do at all. Every figure above is reproducible from the open-source harness: see the full benchmark results and methodology.

How ArcadeDB Compares for GraphRAG

The realistic alternatives are Neo4j, Memgraph, FalkorDB, Kuzu, and JanusGraph. Two of them deserve a straight answer: Memgraph and FalkorDB both ship a vector index in the same store as the graph, so the “one engine instead of two” argument is not unique to ArcadeDB and we are not going to pretend it is. Where ArcadeDB does differ is licensing and breadth. Memgraph Community is BSL and FalkorDB is SSPL, both source-available rather than open source; ArcadeDB is Apache 2.0, which matters if you distribute software built on it. ArcadeDB also stores documents and time series alongside the graph and vectors, and runs embedded in your JVM or Python process rather than only as a server.

That argument does not win everywhere, and the honest version, including where each alternative is the better choice, is in our comparison of open-source knowledge graph and GraphRAG databases. If you are building agent memory specifically, see building memory for LLM agents with ArcadeDB.