The "which vector database should I use?" question comes up on nearly every RAG project. The honest answer is that the differences between the major options have narrowed: all of them support approximate nearest-neighbour search, metadata filtering and, in one form or another, hybrid keyword-plus-vector retrieval. The right choice is mostly about your existing stack, your scale, your tenancy model and how much operational overhead you can absorb.
pgvector: the right default for most teams starting out
If you already run Postgres, and most teams do, pgvector turns it into a vector store with a single extension. It supports HNSW and IVFFlat indexes, half-precision and sparse vectors, and combining vector similarity with ordinary SQL filters and joins. You get transactional consistency with the rest of your data, no extra system to operate, and your existing backups, monitoring and access control keep working.
Into the low millions of vectors on a reasonably sized instance, performance is usually fine for interactive RAG. Beyond that it depends heavily on embedding dimensions, filter selectivity, available memory and write load, so benchmark with your own data. Two practical notes: HNSW indexes on the standard vector type support up to 2,000 dimensions (halfvec raises the limit), and heavily filtered queries need care, which recent versions address with iterative index scans. The details are in the pgvector documentation.
This is the right default for the first year of most products. Migrate later only if you actually hit a limit.
Pinecone: when you don't want to operate anything
Pinecone is the path of least operational resistance: fully managed, with a serverless option, namespaces for partitioning data and no servers to size. The trade-off is cost and control. Usage-based pricing is attractive at small scale; at high query or storage volumes, model the bill carefully against self-hosted options, and check region availability if you have data residency constraints.
Pinecone fits when the team is small, operations bandwidth is close to zero, and the workload is predictable enough to forecast spend.
Qdrant: a strong self-hosted option
Qdrant has matured into one of the cleanest self-hosted vector databases: written in Rust, deployable as a single binary or container, with a managed cloud if you want it later. Payload (metadata) filtering is a strength, and its quantisation options help keep memory costs down at large scale. If you run in your own VPC and care about cost per query at high volume, Qdrant is often the answer. The Qdrant documentation covers deployment and quantisation options.
Weaviate: when the schema and modules matter
Weaviate's strength is its module system, with built-in vectorisation integrations, generative search modules and native multi-tenancy. It suits systems with many tenants, such as B2B SaaS where each customer's data must be isolated, and teams that want the database to own more of the pipeline. The trade-off is another system to learn and operate, or a managed service to pay for.
Side-by-side
| Factor | pgvector | Pinecone | Qdrant | Weaviate |
|---|---|---|---|---|
| Hosting | Wherever your Postgres runs | Managed only | Self-hosted or managed | Self-hosted or managed |
| Ops burden | Low if you already run Postgres | Lowest | Medium | Medium |
| Best at | Simplicity, joins with app data | Zero-ops scaling | Filtering, cost at volume | Multi-tenancy, built-in modules |
| Watch for | Tuning at larger scale | Spend at high volume | Owning upgrades and backups | Learning curve |
Decide with an evaluation, not a benchmark chart
- Take a representative sample of your corpus and a set of real queries with known relevant documents.
- Measure retrieval quality (recall at k) and latency using your real filter patterns, not unfiltered top-k.
- Load-test at the size you expect over the next 12–18 months, not five years out.
- Price the full cost: compute, storage, replicas, backups and the engineering time to run it.
Retrieval quality is usually driven more by chunking, the embedding model and hybrid search than by the choice of database.
Plan for migration from day one
- Put retrieval behind a small interface in your code so the store can be swapped without touching the rest of the application.
- Keep source text and metadata in your system of record, not only in the vector store.
- Record the embedding model and version with each vector. Changing models means re-embedding everything, so budget for it.
Signals that it is time to move off pgvector
- Vector queries are competing with transactional traffic for memory and CPU, and a read replica no longer solves it.
- Index builds or rebuilds take long enough to disrupt deploys or re-embedding runs.
- Filtered queries keep missing relevant results, or keep getting slower, even after tuning.
- You need strict per-tenant isolation or quotas that are awkward to express in one Postgres database.
If none of these apply, the migration is probably premature. A dedicated store adds a second source of truth to keep in sync, and that cost does not show up in benchmarks.
The one factor that usually decides it
Your team's operational profile beats every benchmark. If your team runs Postgres well, use pgvector and stop worrying about it. If your team has no operations capacity, use a managed service such as Pinecone. If you have a strong infrastructure team and care about cost at volume, Qdrant. If multi-tenancy is the core requirement, look hard at Weaviate. Choose for the boring operational reality, not the marketing.
How we apply this at Velura Labs
On RAG & Knowledge Systems projects we typically start on pgvector and migrate only when there is a genuine reason, usually scale well into the millions of vectors or a specific tenancy requirement. For the broader architecture choices, see our multilingual RAG playbook. Talk to us if you'd like a recommendation for your specific corpus and scale.
Our clients for this span US tech hubs (San Francisco, Seattle, Austin, New York), European markets (Paris, Milan, Rome), the Middle East (Dubai, Riyadh, Abu Dhabi) and India. Start a conversation from anywhere.