# 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.