Skip to content

pgvector

Postgres extension that adds vector columns and HNSW or IVFFlat indexes, so embeddings live next to the rows they describe.

Reviewed by Sheela · Updated

View on GitHub Open source

Our rating

4.6/5

For most teams already on Postgres, a dedicated vector database is extra infrastructure that pgvector makes unnecessary.

What it is

pgvector adds a vector data type and similarity search to PostgreSQL. You store embeddings in an ordinary table column and query them with SQL, joining against your other data and filtering with normal WHERE clauses, inside the same transactions.

Without an index it does exact search. For speed it offers two approximate indexes: HNSW (a layered graph, better recall, more memory) and IVFFlat (clusters, faster to build, weaker recall). It supports full-precision, half-precision, binary and sparse vectors. The standard vector type stores up to 16,000 dimensions but indexes only 2,000; half precision indexes up to 4,000 and binary up to 64,000. Version 0.8.0 added iterative index scans, which keep searching until enough rows pass your filter.

It supports Postgres 13 and later, though the unreleased 0.9.0 drops 13 and 14, and it is available on almost every managed Postgres service. The latest release, 0.8.7 on 1 October 2026, fixes a security flaw that can lead to code execution.

Our review

pgvector removes a whole service from your stack. Embeddings sit in the same database, the same backups and the same transactions as the documents they describe, so there is no second store to keep in sync and filters are plain SQL. It has about 23,450 GitHub stars and only 17 open issues, and the unreleased 0.9.0 is already in the changelog.

The comfortable range is narrower than marketing suggests. Encore, which sells Postgres hosting, puts it level with Pinecone below about five million vectors at moderate load (hundreds of queries per second), with careful tuning of shared_buffers, work_mem and HNSW settings needed from five to ten million. Storage explains why. The README puts each vector at 4 bytes per dimension plus 8, so ten million 1,536-dimension embeddings take about 61.5 GB before any index, and HNSW builds slow sharply once the graph outgrows maintenance_work_mem. Half precision halves that. Past this point, pgvectorscale or VectorChord keep the data in Postgres a while longer.

Filtering needs attention. Approximate indexes filter after the scan, and the README's own example is stark: with the default hnsw.ef_search of 40 and a filter matching 10% of rows, a query returns about 4 results on average. Iterative scans, partial indexes or partitioning by tenant fix it, but none is on by default.

Security fixes arrived in 2026 and are worth acting on. CVE-2026-3172, a buffer overflow in parallel HNSW builds, let a user who can create indexes leak data from other tables (0.6.0 to 0.8.1, fixed in 0.8.2). CVE-2026-18022, an IVFFlat build overflow on 32-bit systems only, was fixed in 0.8.6, and CVE-2026-103484, also in IVFFlat builds, can lead to arbitrary code execution in every version up to 0.8.6 and is fixed in 0.8.7. On a managed service, the extension version follows the provider's schedule rather than yours, which is the real argument for checking it before you check benchmark charts.

Where it earns its place

  • A backend engineer at a SaaS company on Amazon RDS

    Add semantic search over two million support tickets

    Add a halfvec column, backfill embeddings, build an HNSW index and join results against the tickets table with ordinary WHERE clauses. At 1,536 dimensions that is roughly 6 GB of vector data, which a modestly larger instance handles without a new service to run.

  • An engineering lead at a B2B start-up with 400 customer tenants

    Keep each customer's documents separate in RAG retrieval

    Partition the embeddings table by tenant or add partial indexes, and turn on iterative scans so filtered queries return full result sets. Row-level security applies as it does to any table, so isolation uses controls the team already audits.

  • A CTO weighing a managed vector database bill

    Decide whether vector search needs its own vendor

    Below about five million vectors at hundreds of queries per second, Encore's guidance favours staying in Postgres: one backup, one access model, no sync jobs. The trade is tuning time when the index outgrows memory.

Before you commit

Setup
On managed Postgres, run CREATE EXTENSION vector; self-hosted, install from source (make, make install) or your package manager for Postgres 13 and later. Upgrade with ALTER EXTENSION vector UPDATE in each database.
Integrations
Any Postgres client or ORM; libraries in most languages wrap the vector type. Supported on the large managed services listed in the project's hosted-providers issue, and used as a backend by RAG tools such as Open WebUI.
Data and privacy
Everything stays inside your Postgres instance under its existing backups, roles and row-level security; the extension sends nothing anywhere. The PostgreSQL License places no limit on commercial use.
Cost at scale
No licence cost; you pay for a larger database. Each vector takes 4 bytes per dimension plus 8, so ten million 1,536-dimension vectors need about 61.5 GB (half that as halfvec) plus index, and builds want maintenance_work_mem large enough to hold the graph.
Limits
Index caps of 2,000 dimensions (4,000 half precision), post-scan filtering that needs iterative scans, slow HNSW builds once memory runs out, no horizontal sharding, and 0.9.0 will drop Postgres 13 and 14.

What's good

  • No extra service: vectors, rows and transactions in one place
  • Filters and joins in plain SQL
  • Available on nearly every managed Postgres
  • Permissive PostgreSQL License

What's not

  • Default filtered queries can return far fewer rows than asked for
  • Indexes only 2,000 dimensions on the standard type
  • Three 2026 CVEs, one allowing code execution before 0.8.7
  • Not built for billions of vectors or very high query rates

Best for

Teams already on Postgres building RAG or semantic search over a few million vectors.

Alternatives

pgvector: common questions

Is pgvector worth it?
For most teams already on Postgres, a dedicated vector database is extra infrastructure that pgvector makes unnecessary. We rate it 4.6 out of 5.
How much does pgvector cost?
Free and open source under the PostgreSQL License. The only cost is the Postgres instance you already run, or a larger one.
What are the downsides of pgvector?
Default filtered queries can return far fewer rows than asked for; indexes only 2,000 dimensions on the standard type; three 2026 CVEs, one allowing code execution before 0.8.7; not built for billions of vectors or very high query rates.
Who is pgvector best for?
Teams already on Postgres building RAG or semantic search over a few million vectors.
How much does pgvector cost for a team or in production?
No licence cost; you pay for a larger database. Each vector takes 4 bytes per dimension plus 8, so ten million 1,536-dimension vectors need about 61.5 GB (half that as halfvec) plus index, and builds want maintenance_work_mem large enough to hold the graph.
Is pgvector safe for company data?
Everything stays inside your Postgres instance under its existing backups, roles and row-level security; the extension sends nothing anywhere. The PostgreSQL License places no limit on commercial use.
What are the best pgvector alternatives?
The closest alternatives we have reviewed are Qdrant, Milvus, Weaviate, LanceDB and Chroma.

Answers checked Oct 23, 2026.

Make pgvector? Show this rating on your sitepgvector rated 4.6 out of 5 on ReviewRamble