pgvector

Vector search inside Postgres. The default for teams already on Postgres or Supabase.

VISIT PGVECTOR

Key takeaway: If your app already has a Postgres database, the vector store question is mostly answered: put the embeddings in the same database and skip the second system. Reach for a purpose-built engine like Qdrant or Pinecone only once you can name the specific limit pgvector hit, whether that is vector count, index build time, or p99 under concurrency.

Quick facts

  • CategoryEmbedded
  • EngineC / Postgres extension
  • PricingOpen source
  • LicensePostgreSQL License
  • Created2021
  • GitHub stars13.5k
  • Hybrid searchNative
  • Edge-readyNo
  • Multi-tenantNative
  • Max dimensions16,000

What it is

pgvector is a Postgres extension that adds vector similarity search to standard Postgres. Cosine, L2, and inner-product distance, HNSW + IVFFlat indexes, exact and approximate search. Runs anywhere Postgres runs (Supabase, Neon, RDS, Aurora, your laptop). The default vector store for the Postgres-aligned half of the AI ecosystem.

Further reading

Best for

  • RAG apps already running on Postgres / Supabase
  • Workloads under 50 million vectors where horizontal sharding is not yet the constraint
  • Teams that want vector + relational data in one query (vector + JOIN)
  • Cost-sensitive deployments, the bill is whatever Postgres costs

When not to pick it

Skip pgvector for genuinely massive vector workloads (>100M vectors, sub-50ms p99 latency at high concurrency), purpose-built engines like Pinecone or Qdrant pull ahead. Skip if your stack does not already involve Postgres.

My take

pgvector is the answer most RAG apps should reach for first in 2026. The "do I need a separate vector DB?" question almost always resolves to "no, pgvector is fine" until the workload genuinely outgrows it. Single source of truth, no sync, lower bill.

Index choice is where pgvector is won or lost

The extension ships two index types and they are not interchangeable. HNSW is slower to build and hungrier for memory, but it holds recall well as the table grows and does not need rebuilding every time you double the row count. IVFFlat builds quickly and stays small, but it wants a populated table before you create it, and its list count has to be retuned as data lands or recall quietly degrades. Neither is set and forget. Recall is a per-query knob and the defaults lean toward speed over accuracy, so a RAG pipeline returning mediocre chunks is often an untuned search parameter rather than a bad embedding model. One more trap worth knowing before you pick an embedding model: the number of dimensions Postgres will store in a vector column is considerably higher than the number it will actually index, so very wide embeddings have to be reduced before any index will accept them.

One database, one transaction, no sync job

The strongest argument for pgvector has nothing to do with search quality. It is that embeddings sit next to the rows they describe, so you can filter by tenant, join to the source document, and enforce row-level security in the same statement that ranks by distance. There is no replication job to write, no eventual consistency between two stores, and no second thing to back up or pay for. The cost shows up elsewhere. Vector search competes with your transactional workload for the same buffer cache and CPU, and a large index build can degrade the app while it runs. Postgres also scales vertically here, so past a certain vector count you are choosing between a very large instance and sharding by hand. That is usually the moment to move vectors to Qdrant and keep Postgres as the source of truth.

Frequently asked questions

Is pgvector fast enough for production RAG?

For most RAG apps, yes. Millions of vectors with a tuned HNSW index and sensible filtering are well within reach on a decently sized instance. The honest limits are concurrency and index build time rather than raw search speed, and both bite before recall does. Benchmark with your own filter patterns before assuming you need a dedicated engine, because filtered search is where results diverge most between engines.

pgvector or Pinecone?

pgvector when Postgres is already in the stack and the bill matters, because you get vectors, relational data, and one backup story for the cost of the database you were already running. Pinecone when you want the vector layer to be somebody else's operational problem, low latency at high concurrency is a hard requirement, and hosted-only is acceptable to your compliance team.

Does pgvector work with Supabase and Neon?

Yes. Both ship the extension, so enabling it is a single statement rather than an infrastructure project, and it works the same way on RDS, Aurora, or a Postgres container on your laptop. That portability is a large part of why pgvector became the default for the Postgres-aligned side of the AI ecosystem: the store is already provisioned, already backed up, and already inside your connection pool.

Links

Compare pgvector side-by-side

pgvector vs Pinecone → pgvector vs Chroma → pgvector vs LanceDB → pgvector vs Qdrant →

Similar tools you should also consider

Chroma

Embedded vector database for AI apps. Runs in-process like SQLite, prototype-first.

Read the take →

LanceDB

Embedded multimodal vector + tabular database. Object-store-backed, Rust-fast.

Read the take →

Qdrant

Rust-fast open-source vector engine. Cleaner API than Weaviate, smaller footprint.

Read the take →

If pgvector is your pick, the next conversation is short

The 30-min call is where your vector-DB choice becomes a real RAG architecture, a chunking + reranking strategy that actually works for your corpus, and a price range you can take to your stakeholders. Describe your data shape, your query patterns, your latency budget. I tell you whether pgvector is genuinely your fit.