Skip to content

Update vector edge index docs #1608

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
gitbuda merged 3 commits into from
May 3, 2026
+7 −11
Merged

Update vector edge index docs #1608

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
b63699a
Update vector edge index docs for the single-store refactor
DavIvek Apr 29, 2026
a087f71
Tighten vector index intro: list what actually differs
DavIvek Apr 29, 2026
88e91d5
a few improvements
DavIvek Apr 29, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
18 changes: 7 additions & 11 deletions pages/querying/vector-search.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -19,10 +19,7 @@ specifically operates at `READ_UNCOMMITTED`. This design maintains all
transactional guarantees at the database level. Only the vector index
operations use this relaxed isolation level, ensuring the database's ACID
properties remain intact for all other operations.
Memgraph supports two kinds of vector indexes:

- **Single-store vector index on nodes**. The vector value is stored only in the vector index backend (USearch); the property store keeps only a reference (vector index ID). This avoids duplicating vector data between the property store and the index.
- **Vector index on edges**. This uses a different storage model: the vector remains in the edge property store and is also indexed in USearch. Creating, querying, and dropping edge vector indexes is done with separate syntax and procedures from the single-store (node) index.
Memgraph supports vector indexes on both **nodes** and **edges**. Both use the same **single-store** pattern: the vector value is stored only in the vector index backend (USearch), and the property store keeps only a reference (a vector index ID). This avoids duplicating vector data between the property store and the index. The creation syntax (`CREATE VECTOR INDEX` vs. `CREATE VECTOR EDGE INDEX`) and the search procedure (`vector_search.search()` vs. `vector_search.search_edges()`) differ between the node and the edge variant; `DROP VECTOR INDEX` and `SHOW VECTOR INDEX INFO` work for both.

<Callout type="warning">
To configure vector search as described in the example, please use the latest Memgraph version.
Expand All @@ -36,11 +33,10 @@ systems to find entities based on semantic similarity rather than exact matches.

## Create vector index

To run vector search, first create a vector index. The syntax and storage behavior differ for nodes and edges.

### Single-store vector index
To run vector search, first create a vector index.
### Vector index on nodes

Single-store vector indices are created with the `CREATE VECTOR INDEX` command. You need to:
Vector indexes on nodes are created with the `CREATE VECTOR INDEX` command. You need to:

1. Provide the index name
2. Specify the label and property it applies to
Expand All @@ -64,7 +60,7 @@ CREATE VECTOR EDGE INDEX vector_index_name ON :EDGE_TYPE(embedding) WITH CONFIG

### Configuration parameters

The following options apply to both single-store vector indexes (nodes) and vector indexes on edges:
The following options apply to vector indexes on both nodes and edges:

- `dimension: int` ➡ The dimension of vectors in the index.
- `capacity: int` ➡ Minimum capacity for the vector index, which prefers powers of two and is adjusted internally for optimal performance but will be at least the given value.
Expand Down Expand Up @@ -130,7 +126,7 @@ Additionally, the same information can be retrieved with the `SHOW VECTOR INDEX
- `metric: string` ➡ [Similarity metric](#similarity-metrics) used for vector search.
- `size: int` ➡ The number of entries in the vector index.
- `scalar_kind: string` ➡ The [scalar kind](#scalar-kind) used for each vector element.
- `index_type: string` ➡ The type of the index. For a single-store vector index on nodes, the output is `label+property_vector`; for an index on edges, it is `edge-type+property_vector`.
- `index_type: string` ➡ The type of the index. For a vector index on nodes, the output is `label+property_vector`; for a vector index on edges, it is `edge-type+property_vector`.

{<h3 className="custom-header"> Usage: </h3>}

Expand Down Expand Up @@ -263,7 +259,7 @@ DROP VECTOR INDEX vector_index_name;
```

<Callout type="warning">
**Single-store vector index (nodes only):** When you drop a single-store vector index, Memgraph must move all vector data from USearch back into the property store. Every affected node's property is rewritten from a vector index ID to the full vector. This can be **slow** (one write per indexed node) and **memory costly** (vectors are stored in the property store as 64-bit values, increasing property store size).
**Drop cost:** When you drop a vector index, Memgraph must move all vector data from USearch back into the property store. Every affected node's or edge's property is rewritten from a vector index ID to the full vector. This can be **slow** (one write per indexed entry) and **memory costly** (float components are stored in the property store at the precision set by `--storage-floating-point-resolution-bits`, default 64-bit, increasing property store size).
The same effect occurs when you **remove a label** from a node that had a vector index on that label: if no other vector index references that property, the vector is restored from USearch to the property store. Plan accordingly when dropping indexes or changing labels on large datasets.
</Callout>

Expand Down