Decision guide
Vector Databases Compared
Where should you store embeddings for semantic and hybrid search?
Side by side
| Criterion | pgvector (PostgreSQL) | Dedicated open-source vector DB | Managed serverless vector DB | Search engine with vectors |
|---|---|---|---|---|
| Operations | Your existing database | Another service to run | Provider-run | Your existing cluster (or managed) |
| Keyword + vector (hybrid) | Yes, with full-text search and rank fusion in SQL | Built in on most | Supported (sparse + dense) | Strongest keyword search |
| Filtering and permissions | Full SQL, joins, row-level security | Rich payload filters | Metadata filters, namespaces | Rich filters, document-level security in some editions |
| Scale | Single node up to tens of millions of vectors comfortably | Horizontal scaling | Provider scales | Horizontal scaling |
| Consistency with your data | Same transaction as the source rows | Sync pipeline needed | Sync pipeline needed | Sync pipeline needed |
| Cost model | Your database resources | Your servers | Usage-based | Your cluster or managed pricing |
When to choose each
pgvector (PostgreSQL)
Vectors in a column of your PostgreSQL tables, with HNSW or IVFFlat indexes, next to the rest of your data.
Choose when
- You already run PostgreSQL
- Up to tens of millions of vectors
- You need joins, transactions and row-level security with your data
Avoid when
- Very large corpora needing distributed search across many nodes
Dedicated open-source vector DB
A database built for vector search that you run yourself (for example Qdrant, Weaviate or Milvus), with filtering and hybrid search.
Choose when
- Vector search is a core workload with heavy filtering
- Large corpora and high query rates
- You can operate another stateful service
Avoid when
- Small projects where another database is overhead
Managed serverless vector DB
A hosted vector service (for example Pinecone) where you pay for usage and the provider runs scaling.
Choose when
- No operations team for another database
- Spiky or unpredictable query volume
- Fast start
Avoid when
- Strict data-residency needs the provider can't meet
- Heavy joins with relational data
Search engine with vectors
Elasticsearch or OpenSearch with vector fields alongside mature keyword search.
Choose when
- You already run Elasticsearch or OpenSearch
- Hybrid search with strong BM25, analyzers and many languages
Avoid when
- You don't need full-text search and want something simpler
Verdict
If you already run PostgreSQL, start with pgvector: one database, transactional consistency, SQL filters and row-level security, and hybrid search with full-text in the same query. Move to a dedicated vector database when vector search becomes a large, filtered, high-throughput workload; choose a managed service to avoid operations; and use Elasticsearch or OpenSearch when you already rely on them for keyword search. Retrieval quality depends more on chunking, hybrid search and reranking than on the database.
Learn more
- Scaling Databases & Data Consistency
- RAG in Production
- Databases & Transactions
- Build hybrid RAG search on PostgreSQL with pgvector (AI & LLM APIs)