Redis (vector search)

What it is and how it works

Redis Stack (and Redis 8+, which folds the search module into core) adds vector similarity search to the same in-memory data engine that has run caches, queues, and session stores for well over a decade. The feature lives inside the FT.SEARCH / FT.AGGREGATE query engine, originally built for full-text and secondary indexing on hashes and JSON documents. Vectors are stored as a field type alongside your normal fields — a product ID, a timestamp, a tag array, an embedding — and Redis indexes that field with either a flat (brute-force) index or HNSW (Hierarchical Navigable Small World), the same graph-based approximate nearest neighbor structure used by Qdrant, Milvus, and most modern ANN libraries. You choose the distance metric (cosine, L2, inner product) at index-creation time.

The architectural distinction that matters is that this is not a bolt-on vector database — it's a query capability grafted onto Redis's existing data model. Everything lives in RAM (with optional AOF/RDB persistence to disk for durability, not for serving), so lookups are single-digit-millisecond regardless of whether you're doing a plain key GET or a KNN vector query. Because vector fields sit next to ordinary Redis fields, you get hybrid queries for free: FT.SEARCH can combine a vector KNN clause with tag filters, numeric range filters, and full-text matching in one round trip, using Redis's existing query syntax rather than a bolted-on filter DSL. That's the practical payoff of "search inside the database you already have" — filtering by category:electronics AND price:[10 100] alongside a KNN clause doesn't require a second system or a client-side join.

The tradeoff is baked into the architecture: HNSW graphs and flat indices in Redis are memory-resident, full stop. There's no disk-backed index tier, no memory-mapped fallback the way some purpose-built vector stores offer for cold data. Every vector you index costs RAM for the vector itself, the HNSW graph edges, and Redis's own per-key overhead. This is a deliberate design choice that trades scale-to-disk flexibility for the low, predictable latency Redis is known for.

Deployment patterns

Solo/prototype: docker run redis/redis-stack (or redis-stack-server for a headless variant) gets you a working vector index in one command, with RedisInsight as an optional GUI for poking at the data. This is the common path for RAG prototypes where the team already has Redis running for caching or sessions and wants to avoid standing up Qdrant or a managed Pinecone account just to test an embedding pipeline. FT.CREATE defines the index schema (vector field dimensions, algorithm, distance metric) once; ingestion is then just HSET or JSON.SET calls with the embedding as one field among others.

Homelab/small team: Redis with persistence enabled (AOF + periodic RDB snapshots) running as a systemd service or Docker container with a mounted volume. This is where the "already runs in your stack" pitch pays off most: if you're running Redis for job queues (Celery/BullMQ/Sidekiq backends), rate limiting, or caching, adding vector search means one more index definition, not one more service to patch, monitor, and back up. Memory sizing is the main planning task — budget RAM for embeddings (dimension × 4 bytes for float32, times row count) plus HNSW graph overhead, which typically adds a meaningful multiple on top of raw vector size depending on the M parameter.

Team/production server: Redis Cluster for horizontal scaling and sharding, or Redis Cloud (the managed offering) when you don't want to own failover and resharding operations. Redis Sentinel or Cluster mode handles HA. At this scale the RAM-cost-scales-linearly constraint becomes a real budgeting line item — teams either accept the cost for the latency win, tier hot vs. cold data (recent embeddings in Redis, bulk archive in a cheaper store), or move to a disk-capable vector database once collection size passes the point where RAM becomes the dominant cost driver.

How it compares

Against Qdrant, Redis is the "convenience over specialization" choice: Qdrant has richer payload filtering, disk-backed storage options for datasets that don't fit in RAM, and quantization features purpose-built for vector workloads. Redis wins when you already run Redis and want to avoid operating a second stateful service, and when your working set genuinely fits in memory.

Against Milvus, the comparison is similar but starker at scale — Milvus is built for billion-vector collections with distributed sharding, multiple index types tuned for different recall/speed tradeoffs, and GPU-accelerated indexing. Redis's vector search is comparatively simple (HNSW or flat, no GPU path) and is not trying to compete at that scale; it's aimed at datasets where sub-ms latency and operational simplicity matter more than maximum collection size.

Against pgvector, the two are philosophically similar — "add vector search to infrastructure you already run" — but pgvector piggybacks on Postgres's transactional, disk-backed model (better for datasets larger than RAM, ACID guarantees), while Redis piggybacks on an in-memory model (better raw latency, worse cost-per-GB at scale). Teams already on Postgres often prefer pgvector for the same "no new service" logic Redis users apply to Redis.

Best use cases and honest limitations

Redis vector search is the right call when: you already operate Redis in production, your embedding collection is small-to-medium (thousands to low millions of vectors, not hundreds of millions), you need hybrid vector + metadata + full-text queries in a single request, and sub-millisecond latency matters more than exhaustive recall tuning. It's a strong fit for RAG chatbots with a bounded document set, recommendation systems layered on existing Redis-backed product catalogs, and semantic caching (matching incoming queries against previously-seen embeddings) — a pattern Redis itself promotes.

It's the wrong call when your vector collection is large enough that RAM cost dominates your infrastructure bill — that's when Qdrant, Milvus, or a disk-backed store earns its keep. It's also weaker than dedicated vector databases on filtering sophistication, index-tuning knobs, and multi-tenancy features aimed specifically at vector workloads. Teams without existing Redis expertise gain little by adopting it purely for vector search — the value proposition is entirely about reusing infrastructure and operational knowledge you already have, not about best-in-class vector search capability.