Vector Spaces
A "vector space" in MemorySync is the collection that holds a row's embedding plus the metadata that lets the platform filter inside the vector search. This page describes the partitioning, the metric, and the keys that travel with each vector.
One namespace per user
The vector index is partitioned per user. Each row's vector lives in a collection named after the user id (memorysync-user-{user_id}). This partitioning is what lets the platform run scope checks at the index level rather than after the fact.
One index per embedding version
Inside that per-user namespace, vectors are further split by embedding_version — a query is routed to the index whose version matches the query's embedding pipeline.
Distance metric
The index is configured for cosine similarity. The setting is fixed in the platform; per-tenant overrides are not exposed.
Metadata that ships with every vector
| Key | Why it travels with the vector |
|---|---|
memory_id | Maps the vector back to the row in the primary store. |
tier | Lets the index pre-filter by hot/warm/cold. |
retention_status | Lets the index drop archived/deleted rows before scoring. |
environment | Keeps development and production vectors apart at search time. |
project_id | Project-scoped queries filter on this without joining the primary store. |
tags | Allows tag-restricted recall inside the vector search. |
source | Lets you carve recall by origin (e.g. integrations vs direct API). |
How filters interact with similarity
Metadata filters are applied inside the vector search, not afterwards. That means a filtered query stays consistent with a query result limit — you will not lose relevant rows because the filter was applied post-rank.
Linkage to the primary record
On insert, the index returns an identifier; the platform stores it on the memory row as vector_id (varchar(64), unique). On read, the platform uses vector_id to remove a row from the index when it is hard-deleted.
When things can fall out of sync
- If the embed step fails after the row commits, the row exists with
vector/vector_idnull until the retry path catches up. - Re-embedding under a new model creates a new
vector_id; the old vector is removed from its collection. - Deleting the primary row also removes the vector — but the audit trail still records the event.