pgvector vs Redis: Which Vector Search Backend to Use

pgvector vs Redis is the question teams hit when they need vector similarity search and are deciding between bolting it onto the database they already run and standing up a fast in-memory store for it. It comes down to one trade: do you want durable, cheap vectors that live next to your relational data, or in-memory speed for real-time serving? pgvector is the open-source Postgres extension that keeps embeddings inside your database with full SQL and transactions. Redis is the in-memory store whose vector search wins on raw latency and throughput. That is the whole decision in one line; the rest of this post backs it up with a deciding-factor table, a head-to-head breakdown, and the cases where each one clearly wins.

If you are weighing pgvector against other contenders too, see our Chroma vs pgvector and Qdrant vs pgvector comparisons. This page goes deep on just pgvector and Redis for the searchers who have already narrowed it to those two.

The short answer

• Pick pgvector if you want durable, cost-efficient vector search inside the Postgres you already run, with embeddings sitting next to relational data under full SQL and transactions.
• Pick Redis if sub-millisecond latency and high query throughput are the priority - real-time apps and high-QPS serving where speed beats storage cost.
• Use both when you want pgvector as the durable source of truth and Redis as a fast serving or cache layer in front of it for the hottest queries.

Deciding factor to pick

The rule: choose pgvector for durable, SQL-integrated, cost-efficient vectors, and Redis when latency and real-time throughput dominate.

What each tool is

pgvector is an open-source extension for PostgreSQL (under the permissive PostgreSQL Licence) that adds a native vector type and similarity search to the database. It supports approximate-nearest-neighbour indexes with both HNSW and IVFFlat, and distance operators for cosine, L2, and inner product. Because it lives inside Postgres, your embeddings are durable and disk-based, sit right next to the relational rows they describe, and are queryable with ordinary SQL, joins, and transactions. You run it on any Postgres you control, and most managed Postgres services (RDS, Cloud SQL, Azure, Supabase, Neon) support it. The headline benefit is that you keep one durable system instead of adding a separate vector store.

Redis is an in-memory data store best known as a cache, message broker, and low-latency key-value engine. Its vector search capability - delivered through the Redis Query Engine (formerly RediSearch) and vector sets - lets you index embeddings and run similarity search with very low latency and high throughput, which is exactly what real-time apps want. Because data lives in memory (with persistence options like RDB snapshots and AOF logs), Redis is fast but memory-bound, and RAM costs far more per GB than disk, so it gets expensive to hold large vector counts purely at rest. It is often deployed as a fast serving or cache layer rather than the cheap durable store.

pgvector vs Redis: head-to-head

A few of these dimensions deserve unpacking.

Storage and durability. This is the headline difference. pgvector stores vectors on disk inside a transactional database, so they are durable, survive restarts without special config, and cost the same per GB as the rest of your Postgres data. Redis holds the working set in memory, which is what makes it fast, but means durability comes from snapshot and append-only-log persistence, and capacity is bounded by RAM. If your dataset is large and mostly at rest, pgvector is the cost-efficient home; if it is hot and latency-critical, Redis earns its memory bill.

Latency and throughput. Redis is built for speed. In-memory similarity search delivers sub-millisecond latency and the kind of throughput that real-time and high-QPS apps need, which is exactly why it shines as a serving layer. pgvector is fast too, especially with a well-tuned HNSW index, but it plays in disk-speed territory rather than RAM-speed. For most RAG and search workloads pgvector is more than fast enough; for the tightest real-time budgets, Redis is the speed-first choice.

Data living together. With pgvector, an embedding sits in the same row as the relational data it describes, so you can filter, join, and transact across both in one SQL query, with strong consistency. That is a real simplification: no syncing a separate vector store with your database, no dual writes, no consistency drift. Redis keeps vectors apart from your relational data, so you coordinate two systems and accept eventual consistency between them.

Operational footprint. pgvector adds vector search to a database you already run and already know how to back up, monitor, and scale - one fewer system. Redis is a separate service to size, persist, and operate, which is justified when its latency pays for itself but is real extra work otherwise.

Licensing. pgvector ships under the permissive PostgreSQL Licence, so licensing is rarely a concern. Redis licensing shifted: in 2024 it moved its core from BSD to a dual RSALv2 and SSPL source-available model, and in 2025 it added an AGPLv3 open-source option back alongside those. For internal use this changes little, but if you redistribute or resell a Redis-based service, check the current terms.

When to choose pgvector

pgvector wins when durability, cost, and SQL integration matter more than raw latency. Choose it when:

• You already run Postgres and want vector search without adding and operating a separate system.
• Your embeddings should live next to relational data, queryable with SQL joins and protected by transactions.
• You are storing a large number of vectors and want the lowest cost per GB on durable disk.
• You need strong consistency between vectors and the records they describe, with no dual-write syncing.
• Your latency budget is comfortable - RAG, internal search, and recommendations where disk-speed ANN is plenty fast.

In short, pgvector is the default when you want durable, cost-efficient, SQL-integrated vectors and do not need in-memory speed.

When to choose Redis

Redis wins when sub-millisecond latency and real-time throughput are the priority. Choose it when:

• You need ultra-low-latency similarity search for real-time, user-facing features.
• Your workload is high-QPS serving where every millisecond counts and queries are concentrated on a hot set.
• You already run Redis as a cache and want to add vector search to a store you operate.
• Your latency-critical vector set fits comfortably in memory and the speed justifies the RAM cost.
• You want a fast serving or cache layer sitting in front of a durable system of record.

In short, Redis is the pick when speed leads the requirements and you are willing to pay for memory to get it.

Can you use them together?

Yes, and it is one of the better patterns. Use pgvector as the durable source of truth - embeddings stored transactionally next to their relational rows in Postgres you already run - and put Redis in front as a fast serving or cache layer for the hottest, most latency-sensitive queries. Postgres owns consistency and survives restarts cheaply; Redis absorbs the high-QPS real-time reads where sub-millisecond latency matters. You get the cost and durability of disk for the full corpus and the speed of memory for the hot path, instead of forcing one tool to be both the cheap durable store and the ultra-fast serving layer.

Whichever you choose, the backend is only one layer. Retrieval quality depends just as much on your chunking, embedding model, and the quality of the corpus you index, which is why we recommend validating any choice on your own data rather than vendor benchmarks. If you are still comparing pgvector against the field, our Chroma vs pgvector and Qdrant vs pgvector breakdowns cover the other common shortlists.

Cost comparison

The cost story tracks the storage story. pgvector has near-zero licence cost (permissive PostgreSQL Licence) and stores vectors on disk inside a database you likely already pay for, so the marginal cost of adding vector search is small and stays low as vector counts grow. You pay in the same Postgres compute and storage you already operate.

Redis trades storage cost for speed. Its vector search holds the working set in memory, and RAM is far more expensive per GB than disk, so storing millions of vectors purely at rest in Redis costs more than the same data in pgvector. That premium buys sub-millisecond latency and high throughput, which is worth it for a hot serving layer and wasteful for a cold archive. Redis licensing also moved to source-available RSALv2/SSPL with an AGPLv3 option, so confirm terms if you resell a Redis-based service.

The honest summary: at large scale and at rest, pgvector is cheaper; for latency-critical hot data, Redis earns its memory bill. We will not quote specific dollar figures here because both depend heavily on your deployment, managed-service choice, and dataset size - price it against your own workload.

Common pitfalls

• Putting a cold archive in Redis. Holding millions of rarely-queried vectors in memory burns money for latency you do not need. Keep the bulk in pgvector and reserve Redis for the hot set.
• Assuming pgvector is too slow without tuning it. An untuned IVFFlat or default HNSW can disappoint. Tune index parameters (lists, m, ef_search) and check recall before concluding it is not fast enough.
• Treating Redis as durable by default. In-memory means you must configure persistence (RDB and/or AOF) and understand the recovery trade-offs, or a restart can cost data.
• Running two systems with no consistency plan. If you split pgvector and Redis, decide how Redis stays in sync with the source of truth, or you will serve stale vectors.
• Ignoring the licensing shift. Redis is no longer plain BSD. For internal use it rarely matters, but if you redistribute or offer it as a service, review the current RSALv2/SSPL/AGPLv3 terms before you build on it.

Related reading

• Chroma vs pgvector - the other common pgvector shortlist, embedded prototyping store versus production Postgres.
• Qdrant vs pgvector - dedicated Rust vector engine versus vectors inside the database you already run.

Getting help

pgvector vs Redis is the right first question, but the bigger lever is whether your whole retrieval stack - backend, embedding model, chunking, and corpus quality - is set up to deliver answers your users can trust. We help AI teams validate exactly that: the data and models feeding your vector search, and the retrieval quality coming out of it, measured on your own data rather than vendor benchmarks.

Start with a Data Quality Audit to check the embeddings and corpus behind your search, or a Model Validation engagement to verify the models feeding it. Book a free scope call.