pgvector

pgvector is an open-source extension that teaches PostgreSQL, one of the most widely used databases in the world, how to store and search vectors. A vector here is an embedding — a list of numbers that a machine-learning model produces to capture the meaning of a piece of text, an image, or a product. pgvector adds a native vector column type to Postgres, along with the operators to measure how close two vectors are, using distance metrics like cosine similarity or Euclidean distance. With it, you can keep your embeddings right beside your ordinary relational data — a product's description embedding in the same row as its price and stock — and run a query that finds the rows whose vectors are nearest to a search vector. It supports both exact nearest-neighbor search and faster approximate search through index types like IVFFlat and HNSW.

pgvector matters because it brings vector search to a database teams already run, instead of forcing them to adopt and operate a separate specialized system. Semantic search, recommendations, and retrieval-augmented generation all depend on finding the items whose embeddings sit closest to a query embedding, and pgvector makes that a SQL operation. The payoff is integration: you keep transactions, backups, access control, joins, and the rest of PostgreSQL's mature machinery, and you can combine a vector similarity search with ordinary filters in a single query — "find the products most similar to this one, in stock, under fifty dollars." For many teams that is enough, and it avoids the cost and complexity of running a dedicated vector database alongside their main one.

pgvector and Qdrant both do vector similarity search, but they answer to different situations. pgvector is an extension to a general-purpose database — it adds vectors to PostgreSQL, so its great advantage is that you reuse one familiar system for both your relational data and your embeddings, with all of Postgres's reliability and SQL. Qdrant is a dedicated vector database, built from the ground up in Rust purely for vector search, with deep features for filtering, payloads, and scaling that a bolt-on extension does not match at the high end. The trade-off is classic: pgvector wins on simplicity and integration when your vector workload is modest and lives next to relational data; a purpose-built engine like Qdrant wins on raw performance and advanced capability when you have huge volumes of vectors or demanding latency targets.

The honest way to choose is by scale and need, not hype. If you already run PostgreSQL, your embedding count is in the millions rather than the billions, and you value keeping everything in one database, pgvector is often the pragmatic choice and may be all you ever need. If vector search is the core of your product, your volumes are enormous, or you need the specialized indexing, filtering, and horizontal scaling that a dedicated engine provides, a standalone vector database earns its keep. Many teams start with pgvector for its simplicity and migrate to a dedicated system only when they outgrow it. The point is that they are not strictly rivals — one extends a database you have, the other is a system you add — and the right call depends on how central and how large your vector workload truly is.

Use pgvector when its strengths line up with your situation: you run PostgreSQL, your vector data belongs alongside relational data, and your scale is moderate. Choose your index deliberately — HNSW generally gives better query speed for a given recall but builds slower and uses more memory, while IVFFlat is lighter to build — and pick the distance metric (usually cosine for text embeddings) that matches how your model was trained. Lean on the integration that is the whole point: combine vector search with SQL filters so you retrieve semantically similar rows that also satisfy real business constraints, all in one query, and reuse Postgres's backups, security, and transactions rather than reinventing them.

The discipline is to right-size the tool. pgvector shines for retrieval-augmented generation, semantic site search, and recommendations at human scale, but it is an extension, not a specialized engine, so be honest about when you have outgrown it. Watch query latency as your vector count and dimensions climb, tune the index parameters rather than accepting defaults, and plan a path to a dedicated vector database if your workload becomes the center of the product. The failure is to force enormous, latency-critical vector workloads through pgvector and blame the tool, or conversely to stand up a separate vector database when a few million embeddings would have lived happily inside the Postgres you already operate.

pgvector takes its name from PostgreSQL ("pg") plus "vector," and is the open-source extension adding embedding storage and similarity search to that database.

Etymology: source.

Search interest for this term over the last five years:

View interest-over-time on Google Trends →

Areas of marketing where pgvector is a core concern: