What this site is#
pgvector.app is an independent resource for people running vector search inside PostgreSQL with the pgvector extension. It exists because the questions people actually search for — how much recall do I lose with halfvec? how long will this index take to build? why does my filtered query return three rows? — are answered by measurement, not by documentation.
- Not affiliated with the pgvector project, its maintainers, or any database vendor. pgvector's official home is github.com/pgvector/pgvector; bugs in pgvector belong in its issue tracker.
- No sponsors, ads or affiliate links. No vendor has paid for or reviewed anything here.
- Free tools that run in your browser. Nothing you type into a tool is sent anywhere.
How we test#
Every SQL snippet, every error message and every number on this site comes from a real server we set up for this purpose:
| PostgreSQL | 18.6 (PGDG packages, Ubuntu 24.04) |
|---|---|
| pgvector | 0.8.7 (PGDG package postgresql-18-pgvector 0.8.7-1.pgdg24.04+1) |
| Machine | 4 vCPU Intel Xeon @ 2.10GHz (cloud VM), 15 GB RAM |
| Settings | shared_buffers = 4GB, maintenance_work_mem = 4GB, max_parallel_maintenance_workers = 3, jit = off; everything else default |
| Dataset | DBpedia entity abstracts embedded with OpenAI text-embedding-3-large: 500,000 vectors at 1,536 dimensions and 100,000 at 3,072, from the public Hugging Face datasets published by Qdrant |
| Queries | 1,000 held-out articles that are never part of any indexed table |
| Ground truth | Exact top-100 neighbours by cosine distance, computed with NumPy and cross-checked against pgvector's exact (unindexed) search |
Recall@10 is the fraction of the true 10 nearest neighbours an index returns, averaged over the 1,000 queries. Latency is wall-clock time for one query from a Python client over a local Unix socket, after warm-up, with one query in flight at a time — median (p50) and 95th percentile reported. All tables fit in memory, so these are warm-cache numbers; cold, disk-bound performance will be slower. Build times are single runs on an otherwise idle machine.
These numbers describe one machine and one dataset. Your hardware and embeddings will differ, but the shape of the trade-offs — how recall rises with ef_search, what maintenance_work_mem does to build time — carries over. The scripts and raw results are on the benchmarks page so you can rerun them.
How we check facts#
- Behaviour (what a query returns, what an error says) is run on the server above and pasted from the terminal.
- Versions (Docker tags, packages, provider support) are read from each source's own index — Docker Hub, apt/yum repositories, package registries, provider documentation — and dated. Where a source doesn't state something, we say so instead of guessing.
- Things we can't run (a Windows build, a managed provider's console) are described from the upstream README or the vendor's docs, and labelled that way.
- When pgvector ships a release, we rerun the transcripts and benchmarks and update the version badges.
Contact and corrections#
Found something wrong, outdated or unclear? Email hello@pgvector.app. Include the page URL and, for technical issues, your SELECT version(); and pgvector version. Corrections are made on the page and the "Updated" date changes.
We can't debug individual production systems, but we read everything and add recurring problems to troubleshooting.
How the site is built#
Static HTML with no framework, served from Cloudflare. Charts are drawn in your browser from the measured data, and every chart has a table view. No cookies are set for tracking beyond Google Analytics — see the privacy statement.