Most LlamaIndex setups end up with two separate backends once you go beyond plain vector search: a vector store for , and a separate graph database for 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 Both integration packages are independently published on PyPI: Vector store — standard RAG The vector store implements the full ABC — , , , , , plus the async surface.
Metadata filtering supports the full grammar: all 12 operators (, , ///, , , , , , ) with // 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: Property graph store — GraphRAG This is the part that usually needs a second database.
Not here: The graph store implements the full ABC with both and — including , the depth-bounded BFS primitive that actually depends on under the hood. 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 is all you need — no waiting on a docs PR to land anywhere.