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.
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:
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)
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.
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.
48 tests against a live engine via docker-compose (23 vector + 25 graph), plus runnable notebooks with real HuggingFace MiniLM embeddings (384 dims):
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.