# Using SynapCores as a LlamaIndex Vector Store + Property Graph Store

> Source: <https://dev.to/synapcores/using-synapcores-as-a-llamaindex-vector-store-property-graph-store-47f7>
> Published: 2026-08-27 12:21:24+00:00

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.