Using SynapCores as a LlamaIndex Vector Store + Property Graph Store

A developer has published a walkthrough demonstrating how to use SynapCores as a unified backend for both LlamaIndex vector and property graph stores, eliminating the need for separate databases. The integration packages, llama-index-vector-stores-synapcores and llama-index-graph-stores-synapcores, implement the full LlamaIndex abstractions, supporting metadata filtering and graph traversal. The project includes 48 tests and runnable notebooks with real embeddings.

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 https://synapcores.com 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: python 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: python 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.