PostgreSQL with pgvector is good enough for production RAG in the majority of enterprise deployments, particularly when the corpus is in the thousands to low millions of chunks and query volume is moderate. Since pgvector version 0.7, HNSW indexing gives approximate nearest neighbor search with recall and latency competitive with dedicated vector databases at that scale, and running vectors inside Postgres means the team gets transactional consistency, existing backup and replication tooling, and row-level security for access control without adding a new system to operate. The tradeoffs appear at higher scale: index build time grows with collection size, write-heavy workloads can compete with query performance on the same instance, and pgvector lacks some advanced features like built-in sparse-dense hybrid fusion or product quantization that dedicated engines offer out of the box. For a single department knowledge base or a corpus under a few million vectors, pgvector is typically the lower-risk and lower-cost choice; for tens of millions of vectors or strict sub-100-millisecond latency under heavy concurrent load, a dedicated vector database is usually a better fit. Nanobase AI sizes the database choice to the customer's actual document volume rather than defaulting to the most complex option.
The extension is rarely the bottleneck; the configuration around it is
Most complaints about pgvector's production readiness trace back to default configuration rather than a limitation of the extension itself. An HNSW index built with default parameters, a Postgres instance sized for transactional workload rather than vector search, and autovacuum settings untouched from a generic default will underperform regardless of which vector extension is used. Tuning these three areas resolves the majority of pgvector performance complaints before concluding a dedicated vector database is needed.
Most pgvector "limitations" reported in practice are configuration issues, not ceiling effects of the extension.
The tuning checklist in practice
| Area | Default behavior | Production adjustment |
|---|---|---|
| HNSW index build | Conservative m and ef_construction | Increase both for better recall, accepting a longer build time |
| Query-time recall | Default ef_search | Raise ef_search for higher recall on important queries, at a latency cost |
| Autovacuum | Generic table-wide settings | Tune specifically for the vector table, since large embedding rows change dead-tuple math |
| Connection handling | Application-managed connections | Add a pooler such as PgBouncer to avoid connection exhaustion under concurrent retrieval load |
| Memory | Default shared_buffers and work_mem | Size upward so the HNSW graph and working set stay in memory rather than hitting disk |
Each row in this table is a solvable configuration problem, not a reason to abandon pgvector by default.
When tuning stops being enough
Tuning has a ceiling. Once the vector table's index rebuild time starts colliding with the ingestion schedule, once read replicas cannot keep up with concurrent filtered-query load, or once the vector workload is measurably competing with transactional queries for the same instance's resources, no amount of parameter tuning resolves the underlying architectural mismatch, and that is the point to evaluate a dedicated vector engine rather than continuing to tune.
Tuning delays the need for a dedicated vector database considerably, but it does not remove the ceiling entirely.
A realistic production checklist before go-live
- Build the HNSW index with production-representative data volume, not a small test sample, since build time and memory use scale with corpus size.
- Load-test with concurrent queries at expected peak traffic, not sequential single-query tests.
- Confirm autovacuum keeps up under the expected update and delete rate for the vector table specifically.
- Add a connection pooler if the application opens a new connection per request rather than reusing a pool.
- Set up monitoring on index bloat and query latency percentiles, not just average latency.
- Document the re-index procedure for when embedding models are upgraded, since this is a maintenance event teams often forget to plan for.
A pgvector deployment that passes this checklist is production-ready for the great majority of enterprise RAG corpora.
Frequently asked questions
Does pgvector support approximate or exact nearest neighbor search?
Both. pgvector supports exact search by default and approximate search through HNSW or IVFFlat indexes, trading a small amount of recall for substantially faster queries at scale, which is the standard choice for production workloads.
How much does pgvector slow down normal transactional queries on the same database?
If sized and tuned correctly, with adequate memory and a pooler in place, the impact on unrelated transactional queries is typically small. Without tuning, a large vector workload can compete for shared buffer cache and CPU with the rest of the database.
Can pgvector handle filtered vector search efficiently?
Yes, through standard SQL WHERE clauses combined with the vector similarity operator, though very selective filters combined with approximate indexes can reduce recall, which is worth testing against the actual filter patterns used in production.
What happens to a pgvector index when the embedding model changes?
The entire table needs re-embedding and the index needs rebuilding, since vectors from different embedding models are not comparable. This is true for any vector store, not specific to pgvector, and should be planned as a maintenance event.
How Nanobase AI helps
Nanobase AI tunes pgvector deployments to production standard as part of on-premise RAG builds, covering HNSW parameters, connection pooling, and autovacuum configuration specific to the vector workload, and only recommends a dedicated vector database when the workload has genuinely outgrown a well-tuned Postgres instance. See our on-premise LLM deployment guide and solutions for the full stack.
Ready to discuss your project? Contact Nanobase AI or email hello@bumu.tech.