Pgvector vs a Dedicated Vector Database: When Postgres Is Enough
If your data already lives in Postgres, you may not need a separate vector database at all. Postgres full-text search (tsvector and tsquery) handles keyword matching well, and the pgvector extension adds approximate nearest-neighbour search for embeddings, which is often enough for knowledge bases under a few million chunks. This guide explains what each technology does well, where a dedicated vector database earns its keep, and how to decide without guessing.
What Postgres already gives you for search
Postgres has shipped a proper full-text search engine for over a decade. The tsvector type turns a document into a normalised, stemmed list of lexemes, and tsquery does the same for a search phrase. A GIN index on a tsvector column gives you fast keyword lookups with built-in ranking functions like ts_rank and websearch_to_tsquery for natural-language-style queries (quotes, minus signs, OR). None of this is new or experimental: it is the same engine that powers search on countless production applications.
- Exact and partial keyword matching, including stemming ("invoice" matches "invoicing")
- Mature ranking out of the box, with weighting by field (title vs body)
- Transactional consistency: search index updates commit with the rest of your data
- No extra infrastructure, backup pipeline or network hop to manage
- Works well for codes, references, part numbers and exact phrases that embeddings struggle with
The limitation is conceptual. Full-text search cannot connect "cancel my subscription" with a document that only says "terminate your plan". That gap is exactly what embeddings close, and it is the reason most RAG systems end up needing both keyword and semantic retrieval, a pattern covered in more depth in Hybrid Search: Why BM25 Plus Vectors Beats Either Alone for RAG.
pgvector: adding semantic search to Postgres
How pgvector works
pgvector adds a vector column type to Postgres, so you can store an embedding (for example 1536 or 1024 floating-point numbers) alongside the rest of a row. Distance operators let you query by similarity directly in SQL: <-> for Euclidean (L2) distance, <#> for negative inner product, and <=> for cosine distance. Because the embedding sits in the same table as your other columns, you can filter by tenant, date or permissions in the same query, something that is awkward in several dedicated vector stores that treat metadata filtering as a bolt-on feature.
Index types: IVFFlat vs HNSW
pgvector supports two approximate-nearest-neighbour index types, and the choice affects both recall and operational cost.
- IVFFlat: clusters vectors into lists and only searches the nearest ones. Faster to build and lighter on memory, but recall drops if the data distribution shifts and the index is not rebuilt.
- HNSW: builds a navigable graph structure. Higher recall and more predictable query latency, but slower to build and uses more memory per vector.
- For most knowledge-base workloads under a few million chunks, HNSW is the safer default; IVFFlat can make sense when you need to rebuild the index frequently and want faster builds.
Postgres full-text vs pgvector vs hybrid
Choosing the right retrieval approach in Postgres
| Capability | Full-text (tsvector) | pgvector alone | Hybrid (both combined) |
|---|---|---|---|
| Exact keyword / code match | Strong | Weak | Strong |
| Conceptual or synonym queries | Weak | Strong | Strong |
| Ranking quality out of the box | Good | Needs tuning | Best, with re-ranking |
| Index build complexity | Low | Moderate (HNSW tuning) | Moderate to high |
| Infrastructure needed | None beyond Postgres | None beyond extension | None beyond extension |
| Typical use case | Reference numbers, policy IDs | Natural-language questions | Production Q&A over documents |
The practical takeaway: pgvector is not a replacement for full-text search, and full-text search is not a replacement for embeddings. Running both inside the same Postgres database, then merging or re-ranking the results, gives you most of the benefit of a sophisticated retrieval stack without introducing a second data store. This is the same reasoning behind chunking strategies for RAG: good retrieval depends on combining complementary signals, not on picking a single clever technique.
When a dedicated vector database earns its keep
Postgres with pgvector is genuinely competitive for a large share of real-world knowledge bases. A dedicated vector database (Qdrant, Weaviate, Milvus, or a managed service) starts to make more sense once you hit specific operational pressures rather than a round number of vectors.
- Very high scale: tens of millions of vectors with sub-100ms latency requirements, where horizontal sharding and purpose-built ANN implementations outperform a single Postgres instance
- Independent scaling of search traffic: if query load on vectors needs to scale separately from your transactional database, a dedicated service avoids resource contention
- Frequent re-indexing at scale: some vector databases handle incremental index updates more gracefully than pgvector's current HNSW implementation, where large rebuilds can be costly
- Multi-tenant isolation: dedicated platforms sometimes offer namespace-level isolation and quotas that are simpler to operate than row-level security across millions of rows
- Specialised features: sparse-dense hybrid scoring, built-in re-rankers, or multi-vector representations that are not yet native to pgvector
If none of those apply to you, a migration to a dedicated vector database is often solving a problem you do not have yet, at the cost of an entirely new piece of infrastructure to monitor, secure and back up. For a broader view of how these costs stack up across providers, see Vector Database Cost: What You Are Really Paying For and Pinecone Alternatives for Small Teams: A Practical UK Guide.
Operational trade-offs that matter more than benchmarks
Vendor benchmarks tend to focus on raw query latency at a fixed recall target, but the decision in practice is usually dominated by operational factors.
- Backups: pg_dump or your existing Postgres backup strategy already covers embeddings stored in pgvector columns; a separate vector database needs its own backup and restore testing
- Team skillset: if your team already knows Postgres, adding pgvector is a smaller leap than learning a new query language, SDK and operational model
- Consistency: with pgvector, a write to your documents table and its embedding happen in one transaction; with a separate store, you need to handle eventual consistency and reconciliation
- Monitoring and alerting: one more service means one more set of dashboards, upgrade cycles and security patches to maintain
- Cost structure: Postgres compute and storage scale predictably; some managed vector databases charge per vector or per pod in ways that are harder to forecast, a point covered in What Does RAG Really Cost? Ingestion, Storage, Retrieval and Generation Explained
A sensible default for most teams
Start with Postgres full-text search plus pgvector, combined in a single hybrid query. Revisit the decision only when you have concrete evidence of a bottleneck, query latency breaching your SLA, index rebuilds taking hours, or memory pressure from HNSW at your actual data volume, rather than a projection of future scale.
A short decision checklist
- How many chunks or vectors will you realistically have in 12 months? If it is under a few million, pgvector is very likely sufficient.
- Do your queries need exact keyword matching (reference numbers, legal clause IDs, product SKUs)? If yes, you need full-text search regardless of what you choose for vectors.
- Does your search traffic need to scale independently of your transactional workload? If yes, isolation becomes a real argument for a separate service.
- Can your team operate a second database reliably, including backups, upgrades and monitoring? Be honest about current bandwidth.
- Have you actually measured latency and recall with HNSW at representative scale, or are you deciding from a vendor comparison table?
If building and maintaining this retrieval layer yourself (chunking, embeddings, hybrid scoring, citations) is more infrastructure than you want to own, a marketplace approach can skip the decision entirely. Kopik indexes uploaded documents for hybrid full-text and semantic search automatically, so the pgvector-versus-dedicated-database question becomes someone else's operational problem rather than yours. You can create a knowledge base from PDFs, Word files or Markdown, query it through the website, a REST API, or an MCP server, and keep it private or list it in the catalogue for others to query per question.
For teams who do want to assemble their own stack, including deciding where pgvector fits among the other open-source components, The Open-Source RAG Stack in 2026: Building Blocks and Build vs Buy walks through the wider set of choices beyond just the database layer.
Skip the infrastructure decision entirely
Upload your documents and get hybrid full-text plus semantic search out of the box, no pgvector tuning, no separate vector database to operate.
Further reading
If you are weighing a managed RAG platform against a self-hosted stack more broadly, RAG as a Service Platforms Compared: Which Type Suits Your Organisation? sets out the trade-offs beyond just the vector store, including pricing models and data ownership.
Frequently asked questions
Is pgvector as fast as Pinecone or Qdrant for large datasets?
At modest scale (up to a few million vectors), pgvector with an HNSW index performs comparably for most applications. At very large scale with strict sub-100ms latency requirements, purpose-built vector databases with sharding and specialised ANN implementations typically pull ahead. The gap matters far less than most benchmarks suggest until you actually hit tens of millions of vectors.
Can I use Postgres full-text search and pgvector together in one query?
Yes. A common pattern is to run both a tsvector keyword search and a pgvector similarity search, then merge and re-rank the combined results, or use reciprocal rank fusion. This hybrid approach generally outperforms either method alone, particularly for natural-language questions mixed with exact-term queries.
How many vectors can pgvector handle before performance degrades?
There is no fixed ceiling, but practical experience suggests pgvector with HNSW handles single-digit millions of vectors comfortably on reasonably provisioned hardware. Beyond that, index build time, memory consumption and query latency need careful testing against your own data and query patterns rather than assuming a published benchmark applies.
Should I use IVFFlat or HNSW for pgvector?
HNSW generally gives better recall and more predictable latency and is the safer default for production knowledge bases. IVFFlat builds faster and uses less memory, which can suit workloads where the index needs frequent, fast rebuilds and slightly lower recall is acceptable.
What is the difference between cosine distance and inner product in pgvector?
Cosine distance measures the angle between two vectors and ignores magnitude, which suits most text embedding models. Inner product also accounts for vector magnitude and is faster to compute but only gives meaningful similarity rankings if your embeddings are normalised. Most embedding models used for RAG are designed for cosine similarity, so that is the usual choice.
Do I need to migrate off Postgres once my knowledge base grows?
Not necessarily. Many teams run pgvector in production well past the point where they assumed they would need to migrate, because the operational simplicity of one database outweighs marginal latency gains elsewhere. Migrate when you have measured evidence of a bottleneck, not as a precaution.
Get the Kopik newsletter
New knowledge bases, RAG guides and product news. One email every week or two, unsubscribe in one click.
By subscribing you agree to receive our newsletter. We never share your address.