Vector Search Without Leaving Postgres

You've got embeddings to store and search, and you've got a Postgres database already humming along with your app's data. So why bolt on a separate vector database, sync pipelines, and another service to babysit? pgvector answers that question by making vector similarity search a native part of Postgres, so your vectors live right next to everything else.

What It Does

pgvector is an open-source extension for Postgres that adds vector similarity search to the database you're already running. You store vectors in a column, then query for nearest neighbors using distance operators in plain SQL. That's the whole idea: no separate vector store, no separate query language, just Postgres.

It supports exact and approximate nearest neighbor search, and it handles more than one flavor of vector—single-precision, half-precision, binary, and sparse. On the distance side, you get L2, inner product, cosine distance, L1 distance, Hamming distance, and Jaccard distance. Because it's just Postgres, you get ACID compliance, point-in-time recovery, JOINs, and every other feature the database already offers. And since it's an extension rather than a client library, you can use it from any language that has a Postgres client.

Why It's Cool

• Your vectors and your relational data finally share a home. This is the big one. Instead of exporting data to a vector store and reconstructing context at query time, you can JOIN a similarity search against your existing tables. Filter by user, tenant, or timestamp in the same query that ranks by distance. That's a lot of glue code you don't have to write.

• You get the boring, important stuff for free. ACID compliance and point-in-time recovery aren't exciting, but they're the reason you trust Postgres with everything else. Vector search inherits those guarantees instead of asking you to evaluate a new system's durability story from scratch.

• Multiple vector types and distance metrics, not just one. Half-precision and binary vectors matter when storage or speed is the constraint. Sparse vectors matter for certain retrieval workloads. Having Hamming and Jaccard distance alongside the usual L2 and cosine means you're not locked into a single model of similarity.

• Quantization when your data grows. If you've got a lot of vectors, the README points to quantization as the scaling path. That's a practical acknowledgment that memory is finite and brute-force search doesn't stay cheap forever.

• It installs the way you'd expect an extension to install. Compile and make install, or grab it through Docker, Homebrew, PGXN, APT, Yum, pkg, APK, or conda-forge. It ships preinstalled with Postgres.app and many hosted providers, so there's a decent chance you can skip installation entirely.

How to Try It

The fastest path is to check whether your Postgres provider already has it. If not, build from source on Linux or Mac (Postgres 13+):

cd /tmp
git clone --branch v0.8.6 https://github.com/pgvector/pgvector.git
cd pgvector
make
make install # may need sudo

On Windows, you'll need C++ support in Visual Studio and the x64 Native Tools Command Prompt for VS, then build with nmake:

set "PGROOT=C:\Program Files\PostgreSQL\18"
cd %TEMP%
git clone --branch v0.8.6 https://github.com/pgvector/pgvector.git
cd pgvector
nmake /F Makefile.win
nmake /F Makefile.win install

Once it's installed, enable it in each database where you want it:

CREATE EXTENSION vector;

Create a table with a vector column, insert some data, and query for nearest neighbors:

CREATE TABLE items (id bigserial PRIMARY KEY, embedding vector(3));

INSERT INTO items (embedding) VALUES ('[1,2,3]'), ('[4,5,6]');

SELECT * FROM items ORDER BY embedding <-> '[3,1,2]' LIMIT 5;

The distance operators are <-> for L2, <#> for negative inner product, <=> for cosine distance, and <+> for L1 distance. Note the inner product quirk: it returns the negative value, because Postgres only supports ascending order index scans on operators.

From there you can upsert with ON CONFLICT, bulk load with COPY, and update or delete vectors like any other column. The repo is at github.com/pgvector/pgvector.

Final Thoughts

pgvector isn't trying to be the fastest vector database on the planet, and it doesn't pretend to be. What it offers is a pragmatic trade: you give up some of the raw performance a purpose-built system might squeeze out, and in return you skip an entire category of operational complexity. If your vectors already belong to rows you're storing in Postgres, or if your queries need to combine similarity with relational filters, this is a natural fit. If you're running billions of vectors and nothing else, you'll want to look harder at scaling and quantization first. For most teams sitting somewhere in between, it's worth a look before you reach for another service.