pgvector
open sourceVector similarity search inside Postgres. Usually the right first answer if you already run Postgres.
Directory
Retrieval gives a model facts it was not trained on. You embed your documents, store the vectors, and at query time fetch the nearest few to put in the prompt. The store is the piece that holds those vectors and answers the nearest-neighbour query.
The first decision is whether you need a dedicated one. If you already run Postgres and have fewer than a few million vectors, the extension is very likely enough, and one fewer system to operate is worth more than a benchmark win.
Above that, the differences that matter are rarely raw similarity speed. They are filtering (combining a vector search with ordinary predicates), hybrid search (vectors plus keywords, which beats either alone on most real corpora), and what happens to cost when the dataset is large but mostly cold.
6 tools · 4 open source · 4 self-hostable
| Tool | Best for | Pricing | Runs |
|---|---|---|---|
| pgvectoropen source | Anyone already running Postgres with up to a few million vectors, which is a larger share of real applications than the category implies. | Open source | Self-hosted |
| Qdrantopen source | Filter-heavy retrieval — multi-tenant, permissioned, or time-scoped — where naive filtering degrades results. | Open source | Hosted or self-hosted |
| Pinecone | Teams who want retrieval to be somebody else's operational problem and are content to pay for that. | Usage-based | Hosted |
| Weaviateopen source | Corpora containing identifiers, product codes, or proper nouns, where pure vector search visibly misses. | Open source | Hosted or self-hosted |
| Chromaopen source | Prototyping retrieval, notebooks, and small applications where a service is overkill. | Open source | Hosted or self-hosted |
| turbopuffer | Large corpora where only a fraction is queried regularly, and per-tenant indexes that are mostly idle. | Usage-based | Hosted |
Vector similarity search inside Postgres. Usually the right first answer if you already run Postgres.
Open-source vector database in Rust, with strong payload filtering alongside similarity search.
Fully managed vector database; no infrastructure to run, priced per index and per operation.
Open-source vector database with built-in hybrid keyword-plus-vector search.
Embeddable vector store that runs in-process, which makes it the quickest way to prototype retrieval.
Vector and full-text search built on object storage, priced for large, comparatively cold datasets.
Ask this first and take the answer seriously. At small and medium scale the extension removes a service, a sync problem, and a second consistency model, at very little cost in capability.
Real queries are almost never pure similarity — they are similarity within a tenant, a date range, or a permission scope. How well a store combines filters with vector search is the difference that shows up in production.
Keyword search still beats embeddings on exact names, codes, and rare terms. Stores with built-in hybrid retrieval save you running and reconciling a second search system.
Pricing models differ sharply on data you store but rarely query. Memory-resident indexes charge for capacity; object-storage designs charge closer to what you actually read. On a large cold corpus this dominates the bill.
Not necessarily. If you already run Postgres, the pgvector extension handles small and medium workloads well. A dedicated store earns its place at larger scale, or when you need hybrid search and rich filtering it cannot provide.
Combining vector similarity with traditional keyword search and merging the rankings. It reliably outperforms either alone, because embeddings are weak on exact identifiers and keywords are weak on paraphrase.
Managed removes operational work and adds a vendor in your data path. Self-hosted keeps data and cost under your control and makes scaling your problem. Several open-source options here offer a hosted tier, which keeps the exit open.
Tooling choices rarely dominate a bill; the model does. Compare model prices per million tokens or price your own workload before optimising anything here.