Vector database
A vector database,
built into Postgres.Store embeddings, search by meaning, and power RAG with pgvector, the open-source vector extension for PostgreSQL. Run it on a managed Postgres instance or inside a project, with the same backups, pooling, and scaling as the rest of your data. No separate vector database to run, sync, or pay for.
The basics
What is a vector database?
A vector database stores data as vectors, lists of numbers called embeddings that capture the meaning of text, images, audio, or code. Instead of matching exact keywords, it finds the items whose vectors sit closest to your query, so you can search by meaning and similarity rather than literal words.
Traditional databases are great at exact matches: find the row where the email equals this, or the orders placed after that date. They struggle with a fuzzier question, the one most AI features ask: "what is most similar to this?"
A vector database answers that. You convert your content into embeddings with a model, store those embeddings, and then look up the nearest ones to a new query. Because similar meanings produce nearby vectors, the closest matches are the most relevant, which is exactly what semantic search, recommendations, and RAG need.
The catch is that most teams already keep their real data, users, documents, orders, in PostgreSQL. With pgvector, you do not need a second database for the vectors. Postgres becomes your vector database too.
How it works
How vector databases work,
in four steps.
An embedding model turns text, images, audio, or code into a vector, a long list of numbers that captures meaning. Things that mean similar things end up with similar vectors.
pgvector adds a native vector column to PostgreSQL, so embeddings live in the same table as the rest of your data. There is no separate store to keep in sync.
Build an HNSW or IVFFlat index so similarity search stays fast as your data grows, from a few thousand vectors into the millions.
Ask for the nearest neighbours to a query vector using cosine, L2, or inner-product distance. You get back the closest matches, ranked by meaning instead of keywords.
What people build
What you would use
a vector database for.
Search by intent, not exact words. Return results that mean the same thing, even when the phrasing is completely different.
Ground a language model in your own content. Retrieve the most relevant chunks and pass them to the model as context.
Surface similar products, articles, or tracks by comparing embeddings, instead of maintaining brittle hand-written rules.
Find visually or sonically similar media by embedding the file and looking up its nearest neighbours.
Catch near-duplicate records and content by how close their vectors sit, not by exact string matching.
Flag outliers whose embeddings sit far from everything else, handy for fraud, moderation, and quality checks.
One database, not two
You probably do not need
a separate vector database.
Standalone vector databases mean a second system to provision, secure, scale, and keep in sync with your source of truth. For most products that is more moving parts than the problem deserves.
With pgvector, your embeddings live next to the rows they describe. You can filter by a real column and rank by similarity in the same query, wrap writes in a transaction, and trust one backup to cover all of it.
- ✓ Vectors and rows in one place, joined in plain SQL
- ✓ Real transactions, so embeddings never drift from your data
- ✓ One thing to back up, scale, and pay for
-- nearest documents to a query embedding,
-- for one workspace, newest first on ties
SELECT id, title
FROM documents
WHERE workspace_id = $1
ORDER BY embedding <=> $2
LIMIT 5;The <=> operator is cosine distance. Swap in <-> for L2 or <#> for inner product.
Vector search on Selfhost.dev
A production vector database.
Without the extra database.
Choose Vector Database when you create a Postgres instance, or turn pgvector on in a project database. We run CREATE EXTENSION and tune memory for vector workloads.
Keep embeddings in the same database as your users, orders, and documents. Join them in plain SQL, inside real transactions.
pgvector is open source and standard PostgreSQL. Your data and queries stay portable, with no proprietary vector API to get stuck behind.
Point-in-time recovery, automated backups, encryption at rest, and forking cover your embeddings exactly like the rest of your Postgres data.
PgBouncer pooling, resizing, and Multi-AZ are all included, so vector workloads get the same production treatment as everything else.
Create the database, enable pgvector, and inspect performance from Claude, Cursor, or any MCP client with 150+ MCP tools.
How to choose
pgvector, or a dedicated
vector database?
Pinecone, Weaviate, Milvus, Qdrant, and Chroma are purpose-built vector databases. They are excellent, and they are also a second system. Here is an honest way to decide.
Choose this when
- ✓ You already use Postgres and want one database, not two
- ✓ You need transactional consistency between vectors and your rows
- ✓ You are doing semantic search or RAG into the millions of vectors
- ✓ You want SQL joins, filters, and real backups on your embeddings
- ✓ You would rather not run, sync, and pay for a separate system
Consider one when
- • You are storing hundreds of millions or billions of vectors
- • You need extreme query throughput as a dedicated workload
- • Vector search is your entire product, with no relational data
Even then, many teams start on pgvector and move only the part that needs it. Weighing it up in detail? See our full pgvector vs Pinecone comparison. Comparing the whole field, Pinecone, Qdrant, Weaviate, Milvus, and Chroma? See our guide to the best vector database for RAG.
pgvector vs a dedicated vector database, at a glance
| Factor | pgvector on Postgres | Dedicated vector DB (Pinecone, Qdrant, Weaviate, Milvus, Chroma) |
|---|---|---|
| Architecture | An extension on the Postgres you already run | A separate system to provision and operate |
| Data consistency | Transactional with your rows, no drift | Eventual, kept in sync by a pipeline |
| Querying | SQL joins, filters, and similarity in one query | Vector API, joins handled in your app |
| Scale sweet spot | Comfortably into the millions of vectors | Hundreds of millions to billions |
| Backups & recovery | Same PITR, backups, and forking as Postgres | A separate backup and recovery story |
| Cost | One database bill, from $5/mo | An extra service on top of your database |
Getting started
Turn it on in one click.
We handle the rest.
Pick Vector Database when you create a managed PostgreSQL instance, or enable pgvector on a Postgres database in a project. You can also switch it on for an existing Postgres instance from its settings. We run CREATE EXTENSION vector and tune work_mem and maintenance_work_mem for vector workloads, so it is ready the moment the database is.