Short version: on identical data and parameters, pgvector's HNSW recall was equal to or slightly higher than FAISS's at every ef_search we tried, but each query took about 4.9× longer because it runs through SQL. You choose pgvector for what surrounds the index — transactions, joins, filters, backups, one system — not for raw library speed.
Measured: pgvector vs FAISS#
Both indexes were built over the same 100,000 DBpedia embeddings (OpenAI text-embedding-3-large, 1,536 dims) with the same HNSW parameters — M = 16, efConstruction = 64 — and queried with the same 1,000 held-out vectors, one query at a time.
pgvector HNSW vs FAISS HNSW, same data and parameters
100K × 1,536 dims, M 16, efConstruction 64; points are ef_search 10 → 400. pgvector latency includes SQL parsing, planning and the client round trip; FAISS is an in-process library call.
- pgvector 0.8.7 (SQL, local socket)
- FAISS 1.15.1 (in-process)
| ef_search | pgvector recall | pgvector p50 | FAISS recall | FAISS p50 |
|---|---|---|---|---|
| 10 | 0.815 | 1.4 ms | 0.765 | 0.25 ms |
| 20 | 0.897 | 1.9 ms | 0.871 | 0.35 ms |
| 40 | 0.947 | 2.9 ms | 0.937 | 0.60 ms |
| 64 | 0.970 | 3.9 ms | 0.964 | 0.85 ms |
| 100 | 0.983 | 5.3 ms | 0.977 | 1.1 ms |
| 200 | 0.990 | 9.1 ms | 0.989 | 2.0 ms |
| 400 | 0.995 | 16 ms | 0.994 | 3.7 ms |
| pgvector 0.8.7 | FAISS 1.15.1 | |
|---|---|---|
| Build time (4 vCPU) | 3.4 min* | 26 s (4 threads) |
| Index size | 781 MB on disk | 600 MB serialized |
| Recall@10 at ef_search 40 | 0.947 | 0.937 |
| Median latency at ef_search 40 | 2.9 ms | 0.60 ms |
| Exact search, median | 441 ms (sequential scan) | 58 ms (IndexFlatIP, 1 thread) |
How to read this:
- Recall is the same algorithm's recall. Both implement HNSW from the same paper, so at equal parameters they find almost the same neighbours — pgvector scored 0.815 vs 0.765 at ef_search 10 and 0.995 vs 0.994 at 400. It doesn't trade accuracy for living inside Postgres.
- * The build-time gap is mostly configuration. FAISS used all four threads; our pgvector build ran as a single process because PostgreSQL planned no parallel workers for a table whose vectors live in TOAST. How to fix that.
- The latency gap is mostly not the graph search. A pgvector query is parsed, planned, executed by the executor with tuple-at-a-time overhead, and its results sent over a socket to a Python client. FAISS is a function call on an in-memory array. At low
ef_searchthe fixed per-query overhead dominates. - Exact search shows the storage cost. pgvector reads every vector out of the table (TOASTed, one row at a time); FAISS multiplies one contiguous matrix. That's why pgvector needs an index sooner.
If you want FAISS-like speed and you don't need a database, use FAISS. If you need a database, compare databases — which is the rest of this page. Scripts and raw numbers: benchmarks.
Capability matrix#
| pgvector | Pinecone | Qdrant | Milvus | Weaviate | Chroma | FAISS | |
|---|---|---|---|---|---|---|---|
| What it is | Postgres extension | Managed service | Vector database | Vector database | Vector database | Embedding database | Library |
| Latest version | 0.8.7 | SaaS | 1.20.0 | 3.0.4 | 1.40.2 | 1.5.9 | 1.15.1 |
| License | PostgreSQL | Proprietary | Apache-2.0 | Apache-2.0 | BSD-3 (+ proprietary wl/ dir) | Apache-2.0 | MIT |
| Self-host | ✅ | BYOC via sales | ✅ | ✅ | ✅ | ✅ | Embedded |
| Managed option | Every major cloud's Postgres | ✅ | Qdrant Cloud | Zilliz Cloud | Weaviate Cloud | Chroma Cloud | — |
| ANN indexes | HNSW, IVFFlat | Not disclosed | HNSW | HNSW, IVF*, DiskANN, ScaNN, GPU CAGRA… | HNSW, flat, dynamic, HFresh | HNSW, SPANN (cloud) | Flat, IVF, HNSW, PQ, RaBitQ… |
| Max indexed dims | 2,000 (vector) · 4,000 (halfvec) · 64,000 (bit) | 20,000 | 65,535 | 32,768 | Not stated | Not stated | Not stated |
| Filtering | Any SQL WHERE; iterative scans | Metadata filters | Payload-aware HNSW | Scalar filters | Filters | Metadata filters | ID selectors only |
| Hybrid (keyword + vector) | With Postgres full-text (guide) | Dense + sparse | Sparse vectors | Sparse vectors, BM25 full-text | BM25 hybrid | Substring/regex document filters | — |
| ACID transactions, joins | ✅ Full SQL | — | — | — | — | — | — |
Sources: each project's GitHub README, license file and release tags; Pinecone, Qdrant, Milvus, Weaviate and Chroma documentation on index types and limits; Pinecone's pricing page. Checked 2026-10-27.
When each alternative wins#
Pinecone#
A proprietary, fully managed service, now serverless-first (pod-based indexes are legacy). Plans run from a free Starter tier through Builder ($20/month), Standard ($50/month minimum) and Enterprise ($500/month minimum), with usage billed in read units, write units and storage. Pick it when you want zero operations and elastic scale, and accept a second system holding a copy of your data.
Qdrant#
An Apache-licensed Rust server with HNSW that's aware of payload filters, quantization options and sparse vectors. Pick it when filtered vector search is the core workload and you're happy to run (or buy) a dedicated service.
Milvus#
The widest choice of index types — including DiskANN, ScaNN, RaBitQ variants and GPU indexes — and a distributed architecture on Kubernetes. Pick it for very large collections where a single Postgres server stops being practical.
Weaviate#
A Go server with built-in vectorisation modules and BM25 hybrid search. Note the licence: BSD-3 overall, with an enterprise licence covering one directory of the code.
Chroma#
The quickest way to prototype in Python: embedded mode needs no server. It scales out through Chroma Cloud.
Other Postgres extensions#
Staying in Postgres doesn't mean staying with pgvector's two index types. pgvectorscale (StreamingDiskANN), VectorChord (RaBitQ-based IVF) and the new alpha pg_vectorsearch (PRISM index, Postgres 18+) all build on pgvector's types. Status and licences on the ecosystem page.
Choosing#
| If you… | Start with |
|---|---|
| Already run Postgres and have up to tens of millions of vectors | pgvector — one system, SQL filters and joins, transactional consistency |
| Need vectors and relational data updated atomically | pgvector |
| Want no infrastructure at all | Pinecone, or a managed Postgres with pgvector |
| Have hundreds of millions to billions of vectors | Milvus, Qdrant, or Postgres with sharding (Citus) / DiskANN-style extensions |
| Do offline research or batch similarity in Python | FAISS |
| Are prototyping a RAG demo this afternoon | Chroma, or pgvector in Docker (one command) |
Frequently asked questions
Is pgvector faster than FAISS?
No — FAISS is a C++ library called in-process, while every pgvector query goes through SQL parsing, planning and a client round trip. On our 100K-vector test at the same recall, FAISS's median latency was about 4.9× lower. But FAISS is not a database: no persistence, transactions, filtering on other columns, or concurrent writers. The two answer different questions.
Should I use pgvector or Pinecone?
Use pgvector if you already run PostgreSQL and your vectors fit on one well-provisioned server (into the tens of millions at 1,536 dimensions), and you want joins, transactions and one system to operate. Choose Pinecone if you want a fully managed, serverless vector service and are comfortable with a proprietary, usage-billed product.
When is pgvector the wrong choice?
When the index no longer fits in one machine's memory and you don't want to shard Postgres yourself; when you need very high query throughput on billions of vectors; or when you need specialised features such as GPU indexes or built-in multi-vector (late-interaction) search. Dedicated systems like Milvus or Qdrant, or Postgres extensions like pgvectorscale, target those cases.