pgvector
A PostgreSQL extension that adds vector similarity search to a database you already run.
pgvector adds a vector column type and similarity operators to PostgreSQL. Embeddings live in the same database as the rest of your application data, and a similarity search is just another SQL query, joinable against everything else.
Because it lives inside Postgres, it inherits Postgres: backups, replication, access control, and the operational know-how your team already has. For most retrieval workloads that is the whole pitch: one fewer system to run.
Where it fits
The right call when your data already lives in Postgres and the vector workload is moderate: retrieval without a second database.
Where it does not fit
Strained at very large scale or extreme query throughput, where a purpose-built vector database will serve you better.
Alternatives to pgvector
The closest options on the map, and where each fits instead.
-
Qdrant Dedicated vector database
A strong pick when retrieval needs to combine similarity with metadata filtering, or has outgrown an in-database extension.
Unlike pgvector Hosted API
-
LanceDB Embedded vector database
A fit when you want fast, embedded vector search with no server, especially over data on object storage.
Unlike pgvector Hosted APIMaturity: growing
-
Chroma Embedded vector database
The easiest on-ramp for a RAG prototype, and a fine production store for small to medium workloads.
Unlike pgvector Hosted APIMaturity: growing
-
Redis In-memory vector search
A fit when you already run Redis and want low-latency vector search without operating a separate database.
Unlike pgvector Source availableHosted APIMaturity: mature
How it compares
-
Our pick when a project genuinely outgrows pgvector. The filtered-search performance is the usual reason we make the move.
Pairs with
Commonly used alongside it.
