pgvector vs. a Dedicated Vector Database: When Is PostgreSQL Enough for RAG?

When you add search to a service that uses PostgreSQL for retrieval-augmented generation (RAG), you need to choose where to store and search the content sent to the language model. RAG finds passages relevant to a question and gives them to the model as context. Vector search turns passages and questions into numeric lists called embeddings, then finds passages whose lists are closest to the question’s list.

The pgvector extension adds vector storage and search to PostgreSQL. A dedicated vector database runs as a separate service designed to find similar vectors. PostgreSQL is enough when tests show that pgvector meets your needs for relevance, response time, query volume, and resource use. Keeping the data in PostgreSQL also makes the architecture simpler. Consider a separate service when its filtering, search, or scaling features solve a specific problem in your workload.

No universal vector-count threshold determines the choice. Embedding dimensions and query volume matter, as do metadata filters and update patterns. Service targets also affect the result.

When pgvector fits naturally

pgvector works well when RAG retrieval depends on the same relational data PostgreSQL already stores. A SQL query can combine vector similarity with constraints such as customer, project, or permission group. The service can keep passage text and metadata alongside embeddings, and use ordinary database operations to insert, update, or delete them.

That arrangement also avoids synchronizing a separate vector store with PostgreSQL. A second service can still be the right choice, but it adds another place to manage data consistency and operations.

pgvector supports exact search, which compares a query against every vector. Approximate nearest-neighbor (ANN) search examines fewer likely candidates to reduce search time. Its ANN indexes include HNSW, a graph-based index that searches through connections among vectors, and IVFFlat, which groups vectors into lists. Approximate search trades some retrieval accuracy for speed. With HNSW, for example, increasing the search effort can improve recall, the share of relevant nearest items returned, while increasing query work.

Start with the index and search settings that match your workload, then measure the results. An index that performs well for unfiltered searches does not automatically meet a filtered RAG service’s quality or latency targets.

When filters make retrieval harder

A metadata filter uses descriptive data about a passage, such as its tenant, access group, or document date, to limit search results. These filters affect both relevance and access control, so measure search quality with the filters your service actually uses.

In pgvector’s approximate search, the database applies filtering after the index scan. As a result, a filter that matches only a small share of rows can leave too few results that pass the filter. The pgvector documentation illustrates this with an HNSW search that examines 40 candidates and a filter matching 10% of rows: on average, about four candidates satisfy the filter. That example describes the mechanism, not a general performance guarantee.

Since pgvector 0.8.0, iterative index scans can continue searching until they find enough qualifying rows or reach a configured limit. Searching further takes additional work, so test both the number of results returned and the query latency. For multi-tenant data, pgvector also documents using list partitioning or separate tables to isolate tenants that share an approximate index.

Some dedicated vector databases build filtering into their search strategies. Qdrant’s filterable HNSW design adds graph connections based on indexed metadata and uses a query planner to choose a search strategy. Those features depend on creating indexes for the metadata fields used in filters. Compare them with pgvector using your filters and tenant distribution to see whether they improve your workload.

What a dedicated database can add

A dedicated vector database becomes more compelling when PostgreSQL tuning does not meet a specific requirement. That requirement might be distributed vector capacity, better behavior under strict filters, or a retrieval feature that the existing PostgreSQL stack does not provide.

For example, Qdrant documents sharding and replication, which distribute data and copies across nodes. It also documents hybrid search, which combines vector similarity with lexical search for exact words and phrases. PostgreSQL can combine pgvector with its own text-search capabilities, but pgvector itself does not provide that text search.

Products differ, so evaluate the specific candidate rather than treating “dedicated vector database” as one architecture. Pinecone, for example, describes a managed design that separates vector storage from the resources handling queries in its architecture overview. Such product-specific features can help when they match a measured need; they also introduce another service and its operating model.

Why benchmark results need context

Published results show why broad claims about speed or cost do not settle the choice. Timescale reports that PostgreSQL with pgvector and pgvectorscale achieved 28 times lower p95 latency (the response time at or below which 95% of queries finished), 16 times higher query throughput, and 75% lower cost than Pinecone’s storage-optimized s1 index. The test used 50 million 768-dimensional Cohere embeddings at 99% recall. Those are Timescale’s benchmark results, for a particular PostgreSQL setup, Pinecone index, and test environment. The results do not establish how pgvector alone or another configuration will perform.

A separate PVLDB study compared PGVector with other systems on particular datasets and query types. In one SIFT test with a filter matching 10% of the data, its chart shows PGVector latency rising from about 4 milliseconds at 90% recall to about 20.5 milliseconds at 100% recall. Those approximate chart readings illustrate the cost of pursuing higher recall in that test; they are not predictions for a RAG deployment.

The studies use different systems, data, and test conditions, so they do not form a direct ranking. Benchmark your own embeddings, filters, number of simultaneous queries, update pattern, and target recall. For RAG, assess the quality of retrieved passages as well as database speed: a fast query does not by itself establish that the language model received useful context.

How to decide with your workload

Begin with pgvector when PostgreSQL already holds the data that retrieval needs and SQL filters or joins matter. Test with representative queries and measure recall after filters, p95 latency, query throughput under simultaneous load, data-loading and update performance, and resource use alongside the database’s other work.

Pay particular attention to memory and index maintenance. HNSW performance depends on its index and search settings, and building the index takes less time when its graph fits in PostgreSQL’s maintenance_work_mem. Setting that memory too high can exhaust server memory. For Amazon Aurora PostgreSQL, AWS also advises accounting for concurrent queries and maintenance when sizing memory and monitoring I/O; those recommendations are specific to Aurora, and they identify memory use, concurrent queries, maintenance, and I/O to check in any PostgreSQL deployment. See the AWS production guidance for pgvector.

Move toward a dedicated database when realistic tests show a gap that PostgreSQL tuning does not close, or when a specialized feature solves a concrete requirement. AWS’s RAG service guidance similarly frames the choice around existing PostgreSQL use, latency needs, and specific benefits from other products. Treat that as guidance for AWS options, not a universal rule.

What I'm building

Delegate tasks. Get software.

Give Vroni a GitHub issue, bug report, spec, or rough idea. It reads the repo, plans the change, writes code, runs checks, and works toward a review-ready pull request.

Take a look at vroni.com