Vector Search and GenAI

This section documents the current Neo4j 2026.x calendar-versioned line — Neo4j moved from semantic to calendar versioning (YYYY.MM) in 2025, and the same line applies to the Graph Data Science library — as published at the Neo4j documentation, which is the reference these pages are written and verified against. No specific monthly patch is pinned. Some areas (Aura’s internal infrastructure, the Raft consensus implementation details, and the GDS Pregel API’s low-level internals) are linked, not documented in depth.

This content was generated with the assistance of AI and should be verified against the official documentation before being relied on in production, as Neo4j iterates quickly.

This section’s bibliography lists the reference material consulted while preparing these pages.

Neo4j stores an embedding as a native vector property and indexes it for approximate nearest-neighbor (ANN) search like any other document or vector store, but the property graph underneath is what turns plain vector similarity into GraphRAG — retrieval that also walks relationships for context a bag of nearest embeddings cannot capture on its own.

The VECTOR type and vector indexes

An embedding is stored as a VECTOR-typed property, built with the vector() function from a list of numbers, a dimension count and a coordinate type:

MATCH (m:Movie {title: "The Matrix"})
SET m.embedding = vector($embedding, 1536, FLOAT);

A VECTOR property only becomes ANN-searchable once a vector index exists over it — see Indexes and constraints for the full CREATE VECTOR INDEX syntax, the vector.dimensions / vector.similarity_function options, and how a vector index compares to Neo4j’s other index types. This page assumes that index already exists and focuses on querying it, and on what a graph adds once retrieval has to go beyond a flat top-k list. Full details on the type itself are in the Cypher manual’s Vector type reference.

Querying with the Cypher SEARCH clause

The modern way to run an ANN query in Cypher is the SEARCH clause: it binds a variable from a MATCH pattern to the nearest neighbors of a query vector inside a named vector index, optionally yielding a similarity score:

MATCH (m:Movie)
  SEARCH m IN (
    VECTOR INDEX movie_plot_embedding
    FOR vector($queryEmbedding, 1536, FLOAT)
    LIMIT 5
  ) SCORE AS similarity
RETURN m.title AS title, similarity
ORDER BY similarity DESC;

Older code may still call the db.index.vector.queryNodes(indexName, k, queryVector) procedure for the same lookup — it still runs, but SEARCH is the current, superseding way to express a vector query as a normal part of a Cypher pattern rather than a separate procedure call. See the Cypher manual’s SEARCH clause reference for the full grammar, including combining SEARCH with WHERE pre-filters and other clauses in the same query.

GraphRAG: vector retrieval plus graph expansion

GraphRAG is the pattern of following a vector-similarity retrieval step with a graph traversal step before handing context to an LLM: the vector search finds the chunks or entities most similar to the query embedding, and the graph expansion pulls in the neighbors, related entities, or provenance those hits connect to — context a nearest-neighbor list alone has no way to express. The combined result, not just the raw matches, becomes the context passed to the LLM prompt.

// 1. vector retrieval: the chunks most similar to the query embedding
MATCH (chunk:Chunk)
  SEARCH chunk IN (
    VECTOR INDEX chunk_embedding
    FOR vector($queryEmbedding, 1536, FLOAT)
    LIMIT 5
  ) SCORE AS similarity
// 2. graph expansion: entities each chunk mentions, and their close neighbors
MATCH (chunk)-[:MENTIONS]->(entity)-[:RELATED_TO*1..2]-(context)
RETURN chunk.text AS chunk, similarity, collect(DISTINCT context.name) AS relatedContext
ORDER BY similarity DESC;

A left-to-right GraphRAG pipeline: a query is embedded and matched by vector retrieval

The official neo4j-graphrag-python package packages this pattern — embedding, vector retrieval, optional graph expansion, and prompt assembly — as a Python library purpose-built for Neo4j. On the JVM side, the LangChain4j integration wires Neo4j in as a vector store and graph-augmented retriever for LangChain4j pipelines, and the Spring AI integration does the same for Spring AI’s VectorStore abstraction — both sit above the same driver and object mapping described in Spring Data Neo4j rather than replacing it. The broader catalog of drivers, frameworks and tools in this space is indexed at the Neo4j GenAI Ecosystem, and the Vector Search developer guide walks through the retrieval half of the pattern end to end.

A dedicated treatment of building LLM-powered applications on Neo4j exists — see the bibliography.