I'm unhappy with Redis because it feels wrong for long-term vector storage

That’s a pretty common reaction. Redis is excellent for fast, ephemeral, or cache-like workloads, but it can feel awkward as a primary long-term vector store unless your use case is explicitly centered on low-latency retrieval with a smaller operational footprint.

A good rule of thumb:

• Use Redis for: caching, session/state, temporary embeddings, low-latency lookup, transient ANN indexes
• Use a dedicated vector DB for: durable storage, large-scale similarity search, metadata filtering, lifecycle management, backups, reindexing, and operational clarity

If Redis feels wrong, alternatives are usually better

Depending on your needs:

• Postgres + pgvector
  Best if you want durability, SQL, metadata filtering, and simpler ops. Great default choice.

• Qdrant
  Strong open-source vector database with good filtering, persistence, and straightforward architecture.

• Milvus
  Better suited for larger-scale vector workloads and more specialized retrieval pipelines.

• Weaviate
  Good if you want a richer “vector-native” document model and built-in features.

• Pinecone
  Managed option if you want to offload infra and focus on retrieval use cases.

• OpenSearch / Elasticsearch vector search
  Useful if you already use them for text search and want hybrid search.

A practical way to choose

Ask yourself:

1. Do I need SQL and relational metadata joins?
   → Postgres + pgvector

2. Do I want a purpose-built vector DB with strong filtering and persistence?
   → Qdrant or Weaviate

3. Do I expect very large scale or specialized ANN tuning?
   → Milvus

4. Do I want managed infra and less maintenance?
   → Pinecone

5. Do I already have a search engine stack?
   → Elasticsearch/OpenSearch

My blunt take

If Redis is your main persistent vector store, I’d usually replace it unless you have a very specific reason to keep it. It’s often better viewed as an acceleration layer, not the source of truth.

If you want, I can help you pick the best replacement based on:

• number of vectors
• vector dimension
• update frequency
• filter complexity
• latency target
• self-hosted vs managed