pgvector Review 2026

What is pgvector?

pgvector is an open-source extension for PostgreSQL that adds vector similarity search. Install it, create a column with the vector type, add an index, and query using distance operators. Your embedding vectors live in the same database as your application data, queryable with standard SQL.

It's not a separate database. It's not a new service. It's PostgreSQL with vector superpowers. For the millions of applications already running on Postgres, that's the simplest possible path to vector search.

How It Works

You store vectors in a column of type vector(1536) (where 1536 is your embedding dimension). Then you query with distance operators: <-> for L2 distance, <=> for cosine distance, <#> for inner product. It's SQL. If you know SQL, you know how to use pgvector.

CREATE TABLE documents (id serial, content text, embedding vector(1536));
CREATE INDEX ON documents USING hnsw (embedding vector_cosine_ops);
SELECT id, content FROM documents ORDER BY embedding <=> '[0.1, 0.2, ...]' LIMIT 10;

Three lines. You now have a vector database.

Index Types

HNSW (Hierarchical Navigable Small World)

HNSW is the recommended index type for most use cases. It builds a multi-layer graph structure that enables fast approximate nearest neighbor search. Query performance is excellent, typically single-digit milliseconds for moderate-sized datasets. The tradeoff is build time and memory usage. HNSW indexes take longer to create and use more memory than IVFFlat.

Key parameters: m (connections per layer, default 16) and ef_construction (build quality, default 64). Higher values improve recall at the cost of build time and memory. For most applications, the defaults work well.

IVFFlat (Inverted File Index)

IVFFlat divides your vectors into clusters (lists) and searches only the closest clusters at query time. It builds faster than HNSW and uses less memory, but query performance isn't as good. The key parameter is lists, which controls how many clusters to create. A common rule of thumb: use sqrt(n) lists for n vectors.

IVFFlat requires data to be present before building the index (it needs to learn cluster centers). HNSW can be built on an empty table. For datasets that are loaded once and queried often, IVFFlat is a reasonable choice. For data that changes frequently, HNSW adapts better.

Iterative Scans (v0.8+)

Version 0.8 added iterative index scans, which address a long-standing pain point: filtered vector search. Previously, if you combined a vector similarity search with a WHERE clause, the index might not return enough matching results. Iterative scans keep searching the index until enough filtered results are found, preventing the "overfiltering" problem.

The SQL Advantage

pgvector's biggest strength isn't performance. It's integration. Your vectors live next to your application data. Need the 10 most similar products that are in stock and under $50? That's one SQL query with pgvector. With a separate vector database, you'd query for similar vectors, get IDs back, then query your application database for the matching products. Two roundtrips, two services, more code, more failure modes.

This advantage compounds in applications where vector search is one feature among many. E-commerce search, content recommendations, user matching: these all involve combining vector similarity with business logic filters on relational data.

Cloud Availability

You don't have to install pgvector yourself. AWS RDS for PostgreSQL, Google Cloud SQL, Azure Database for PostgreSQL, Supabase, and Neon all support pgvector. If you're using any of these platforms, enabling pgvector is a one-line command: CREATE EXTENSION vector;. Supabase and Neon have made pgvector a core part of their AI story, with documentation and tutorials specifically for RAG and semantic search use cases.

pgvector vs Pinecone

Pinecone is faster at scale and requires zero infrastructure management. pgvector is free and lives in your existing database. If vector search is your primary workload, Pinecone is the better choice. If vector search is one feature in a larger application that already uses PostgreSQL, pgvector avoids the complexity of a second database.

pgvector vs Weaviate

Weaviate offers hybrid search, built-in vectorization, and multi-tenancy features that pgvector doesn't have. But Weaviate is a separate service to deploy and manage. pgvector adds vector search to what you already run. The choice usually comes down to whether you need Weaviate's advanced features or prefer the simplicity of staying within PostgreSQL.

Who Should Use pgvector?

Ideal For:

• Teams already running PostgreSQL who want vector search without adding a new database to their stack
• Projects that need to join vector and relational data where a single SQL query beats cross-service calls
• Small to medium AI features within existing applications where a dedicated vector database is overkill
• Developers on platforms like Supabase or Neon where pgvector is pre-installed and ready to use

Maybe Not For:

• Large-scale vector search (100M+ vectors) where dedicated databases like Pinecone or Weaviate handle the load more efficiently
• Teams without PostgreSQL expertise since tuning indexes and queries requires database knowledge
• Projects needing hybrid or semantic search features that dedicated vector databases provide out of the box