# Upstash Vector alongside Redis: which data goes where
## The split
- Upstash Vector: embeddings and nearest-neighbor search. Query by
meaning, filter by metadata.
- Upstash Redis: everything with a TTL, a counter, or exact-key
access. Sessions, rate limits, caches, queues, feature flags,
chat history.
Do not store embeddings in Redis and brute-force similarity. Do not
store session TTLs in Vector. Each product is built for its half.
## The join pattern
Keep the vector ID and the Redis key aligned. A common shape:
- Vector index holds document chunks with metadata { docId }.
- Redis holds doc:DOCID with the full text, title, and TTL.
Retrieval: vector search returns chunk IDs, then MGET the Redis keys
for the full payloads. Vectors stay small, Redis serves the bytes.
## Agent memory shape
The Upstash agent-memory tutorial shows the Redis half: working
memory as one TTL key per session, long-term facts in a Redis
Search index. Add Vector when recall needs semantic search over
large fact stores instead of full-text search.
## Auth note
Vector and Redis have separate tokens. The read-only Redis token
trick does not transfer: check each products token scopes before
exposing anything client side.
## Verify
Ingest a document, run a semantic query, and confirm the returned
chunks resolve to full Redis payloads with matching docIds and no
orphans in either store.