Using SynapCores as a LlamaIndex Vector Store + Property Graph Store

#llamaindex #graphrag #vectordatabase #rag

Most LlamaIndex setups end up with two separate backends once you go beyond plain vector search: a vector store for VectorStoreIndex, and a separate graph database for PropertyGraphIndex when you need relationship-aware retrieval (GraphRAG). Two services, two connection strings, two things to keep in sync.

This is a walkthrough of backing both index types with SynapCores instead — one engine, one connection, both index types.

Setup

docker run -d --name synapcores -p 8080:8080 \
  -e AIDB_ACCEPT_LICENSE=1 \
  -v synapcores-data:/var/lib/synapcores \
  ghcr.io/synapcores/community:latest

pip install llama-index llama-index-vector-stores-synapcores llama-index-graph-stores-synapcores

Both integration packages are independently published on PyPI:

Vector store — standard RAG

from llama_index.core import VectorStoreIndex, StorageContext, Document
from llama_index.vector_stores.synapcores import SynapCoresVectorStore

vector_store = SynapCoresVectorStore(uri="http://localhost:8080", embedding_dim=1536)
storage_context = StorageContext.from_defaults(vector_store=vector_store)

docs = [Document(text="SynapCores runs vector search, graph traversal, and SQL in one engine.")]
index = VectorStoreIndex.from_documents(docs, storage_context=storage_context)

query_engine = index.as_query_engine()
response = query_engine.query("What does SynapCores combine into one engine?")
print(response)

The vector store implements the full BasePydanticVectorStore ABC — add, delete, query, delete_nodes, clear, plus the async surface. Metadata filtering supports the full MetadataFilters grammar: all 12 operators (EQ, NE, GT/GTE/LT/LTE, IN, NIN, TEXT_MATCH, TEXT_MATCH_INSENSITIVE, CONTAINS, IS_EMPTY) with AND/OR/NOT and nested groups — so you're not giving up filtering power by moving off a dedicated vector DB.

If you already have data in SynapCores from a previous run:

index = VectorStoreIndex.from_vector_store(vector_store)

Property graph store — GraphRAG

This is the part that usually needs a second database. Not here:

from llama_index.core import PropertyGraphIndex
from llama_index.graph_stores.synapcores import SynapCoresPropertyGraphStore

graph_store = SynapCoresPropertyGraphStore(uri="http://localhost:8080")

graph_index = PropertyGraphIndex.from_documents(
    docs,
    property_graph_store=graph_store,
)

retriever = graph_index.as_retriever()
nodes = retriever.retrieve("What connects to SynapCores?")

The graph store implements the full PropertyGraphStore ABC with both supports_structured_queries=True and supports_vector_queries=True — including get_rel_map(depth=N), the depth-bounded BFS primitive that PropertyGraphIndex.as_retriever() actually depends on under the hood. structured_query() passes Cypher straight through with named-parameter binding if you want to write graph queries by hand instead of relying on the auto-extracted schema.

Why bother

The two index types above are hitting the same SynapCores instance, over the same connection — a vector table and a graph both living in one engine, not stitched together after the fact with a sync job. If you're prototyping GraphRAG and don't want to stand up Neo4j just to try it, or you want vector and graph retrieval to compose in a single query without cross-service joins, this is what that looks like end to end.

Test coverage, for anyone evaluating this seriously

48 tests against a live engine via docker-compose (23 vector + 25 graph), plus runnable notebooks with real HuggingFace MiniLM embeddings (384 dims):

Source + tests: github.com/SynapCores/synapcores-llamaindex
Notebooks: notebooks directory

Both packages are maintained independently of the LlamaIndex monorepo and published straight to PyPI, so pip install is all you need — no waiting on a docs PR to land anywhere.

DEV Community